Installer et configurer StarWind VirtualSAN for VMware ESXi

 

Présentation

 

Le stockage est un des éléments le plus important dans votre environnement virtuel.

Lorsque vous avez plusieurs ESXi et que vous souhaitez utiliser les fonctionnalités vSphere tel que vMotion, SDRS, DRS, etc, vous avez besoin du stockage partagé entre ces ESXi comme NAS et le SAN.

StarWind peut être une alternative à ces technologies en présentant les disques locaux sous forme d’un LUN iSCSI partagé entre les différents ESXi.

StarWind propose une replication synchrone du stockage d’un ESXi vers l’autre. En cas de crash d’un ESXi, toutes les données sont protégées.

 

 

Le gros benefice de cette technologie est l’absence de SAN ou NAS et donc une réelle économie.

Ci-dessous vous trouvez en quelques lignes un résumé de ce que propose StarWind.

 

Problem :

Storage remains the least virtualized element of the datacenter today. Running a dedicated storage server in a converged datacenter introduces multiple drawbacks:

  • Dedicated storage hardware is very expensive because it’s a dedicated server or more often a proprietary piece of equipment. Its upgrade and scalability options are very limited. Hardware storage also introduces significant OpEx increase over time: with every new hardware release vendors increase the service contract prices for legacy hardware support and even cease support for some hardware and announce its EOL (End Of Life) forcing customers to buy brand new hardware, even if the old one still worked fine for them.
  • Any dedicated storage solution adds fabric latency to all I/O operations. Even with high-performance 16/32 Gigabit Fiber Channel or 10/40 Gigabit Ethernet in place, every processed block makes a comparably big number of network hops until it reaches the actual disk.
  • Specially trained staff is required to manage hardware storage solutions. This does not play well with SMBs where there are no storage teams and at times the whole IT infrastructure is managed by one person.

 

Solution :

StarWind Virtual SAN is a pure software defined storage platform which eliminates the need for expensive dedicated storage hardware.StarWind Virtual SAN achieves this by installing the software on the same hardware as the hypervisor, be it Hyper-V, vSphere, or XenServer.VSAN leverages all benefits of the local storage like high performance and minimal latency. It is achieved by bonding all I/O to the local hypervisor node. This provides multiple benefits compared to a dedicated hardware solution:

  • Hypervisor reads from local storage only. High speed synchronization network links are used to replicate writes to the partner hypervisor nodes cache.
  • Cache is local, so the performance gain is much better compared to cache sitting behind slow network.
  • Hypervisor nodes don’t fight for LUN ownership, which increases performance and eliminates unnecessary iSCSI lock overhead.

 

 

 

Si vous souhaitez voir les principales differences entre StarWind et leurs compétiteurs, je vous invite à lire le PDF suivant :

https://www.starwindsoftware.com/whitepapers/differentiationNew.pdf

 

 

INSTALLATION

 

Nous allons dans cet article présenté l’installation de StarWind.

Première étape : Télécharger Starwind : https://www.starwindsoftware.com/starwind-virtual-san-free

Vérifier les pré-requis :

  • Minimum 2 ESXi avec du stockage local
  • Avoir une clé de licence permanente ou temporaire
  • Avoir installé une VM Windows Server sur chaque ESXi

Dans notre cas nous avons un cluster de deux ESXi, avec deux VMs Windows 2012R2 installée en local sur chacun des ESXi.

Sur chaque VM, vous avez besoin de mettre à jour les tools, avoir 2 NIC sur 2 réseaux différents afin de séparer les trafics de synchronisation et de heartbeat.

Dans notre cas, les VMs sont installées sur un petit disque local sur chaque ESXi et il reste un disque de 683 Go sur chaque ESXi. Nous créons donc un datastore VMFS sur chaque ESXi et nous ajoutons un disque sur chaque VM prenant l’intégralité du stockage de ce deuxième VMFS.

Note : Pour de meilleures performances, nous ajoutons ce disque sur un second contrôlleur SCSI VMware Paravirtual :

 

starwind01

 

 

 

 

 

 

 

 

 

 

 

 

 

Sur chaque VM, passez le disque en ligne et initializer le en GPT Table.

 

 

 

Créer la partition StarWind.

 

 

Sur chaque VM, copies ensuite le .exe télécharger au préalable et exécutez le :

 

 

Accepter les agreement :

 

 

Lisez les informations et sélectionnez le chemin d’installation :

 

 

Choisir un type d’installation :

Ici Full Installation.

 

 

Choisir le Start Menu Folder :

 

 

Laissez par défaut :

 

 

Copiez votre licence key :

 

 

Selectionnez Next :

 

starwind02

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Vérifiez les informations et installer :

 

 

Avant la fin de l’installation, le pop-up de configuration du SMI-S Agent apparaît. Cliquer sur No :

 

 

Votre installation de StarWind est terminée. Lancez le via Lauch StarWind management console :

 

 

 

 

CONFIGURATION

 

Lancer StarWind Management Console et choisir Yes pour définir le disque de stockage utilize par StarWind. F:\ dans mon cas.

 

 

Vous devez voir dans Servers, votre serveur locale :

 

 

Ajouter le second serveur StarWind2 via Add Server. Il correspond à la deuxième VM :

 

 

Sur le premier serveur, faites Add Device. Choisir le nom et la capacité de votre premier stockage :

 

 

Cliquez sur Create :

 

 

L’image disque est créée :

 

 

A ce point vous devez avoir l’image disque sur le premier serveur créée :

 

 

Vous allez maintenant devoir configure la replication entre les deux VMs. Pour cela, sélectionnez l’imagefile1 et cliquez sur Replication Manager :

 

 

Sélectionnez Synchronous Replication et renseignez l’ip ou le fqdn du second serveur (deuxième VM dans notre cas) :

 

 

Cliquez sur Create new Partner Device :

 

 

A ce point vous devez vois le chemin du header file sur le disque de destination ainsi que la target name :

 

 

Cliquez sur Change Network Settings :

 

 

Ici vous devez choisir un réseau pour la synchronisation et un réseau pour le heartbeat. Veillez à bien les séparer :

 

starwind03

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Lancez la création du replica :

 

 

A ce point vous avez la nouvelle target partagée créée nommé HAImage1. C’est cette target qui sera utilisé par les ESXi :

 

 

La synchronisation commence :

 

 

Vérifiez sur vos deux serveurs si vous avez les fichiers dans vos disques StarWind :

 

et

 

Désormais, vous pouvez ajouter le stockage partagé sur votre ESXi.

Sur chaque ESXi, ajouter un software iSCSI :

 

 

Editez les propriétés du software iSCSI et ajouter l’ip de votre première VM. Vérifiez si le iqn découvert est le même que celui de HAImage1 :

 

 

Après un rescan, Vous devez voir votre LUN StarWind de 200 Go :

 

 

Creez un nouveau vmfs :

 

starwind04

 

 

 

C’est magique, vous avez un stockage partagé sur vos ESXi composé des disques locaux des ESXi. Désormais vous pouvez utiliser les fonctionnalités vSphere comme vous le voulez.

 

 

 

Share

Comment intégrer au NDFS les appliances Nutanix NX-6035C sous Acropolis Hypervisor – Partie 2

 

 

Partie 1 : Présentation des nœuds capacitifs Nutanix « Storage only node» NX-6035C

Partie 2 : Comment intégrer au NDFS les appliances Nutanix NX-6035C sous Acropolis Hypervisor

 

Nos Nutanix livrés, rackés et comme pour tout nouveau bloc Nutanix, on passe via la procédure de déploiement Nutanix Foundation (à venir prochainement sur vRoomBlog.com)

 

 

Récapitulatif :

  • Serveurs rackés et connectés au réseau (10Gb et IPMI)
  • Acropolis hypervisor est installé sur les noeuds
  • Les CVM poussées

http://www.joshodgers.com/wp-content/uploads/2013/10/Nutanix5NodeCluster.jpg

 

 

Nous allumons nos serveurs, et via la carte IPMI on se connecte à notre premier hyperviseur.

 

 

Login par défaut : ADMIN / ADMIN (Sauf si changé lors de du mastering Foundation)

 

 

 

Sous remote Control => Console Redirection

Launch Console

 

 

On se logue dans l’hyperviseur

Login : root

Mot de passe : nutanix/4u

 

 

Adresse IP

Comme pour une machine Linux mettre une IP :

Configurer IPADDR, MASK, Gateway puis sauvegarder

# vi edit /etc/sysconfig/network-scripts/ifcfg-br0

 

 

 

Mettre un vlan au réseau de management (Si besoin)

#ovs-vsctl set port br0 tag= « vlan ID »

 

 

 

Redémarrer les services

#service network restart or ifdown br0&&ifup br0

 

 

 

Vérifiez votre config via :

# ovs-vsctl show

 

Faite un test Ping

 

 

Configuration de l’Open vSwitch Bridge

Voici le réseau logique d’Acropolis Host avec Open vSwitch

 

 

Depuis notre Host nous allons faire un SSH sur notre CVM

# ssh nutanix@192.168.5.254

 

 

 

Exécuter la commande :

nutanix@cvm$ allssh ‘ssh root@192.168.5.1 /usr/bin/ovs-vsctl add-br bridge br1 && echo success’


Nous créons un bridge de nom “br1”

La sortie devrait ressembler à ça :

Executing ssh root@192.168.5.1 /usr/bin/ovs-vsctl add-br br1 && echo success on the cluster

================== 192.0.2.203 =================

FIPS mode initialized

Nutanix KVM

success

 

 

 

Nous allons connecter nos cartes réseaux à notre agrégat virtuel « Bound0 »

Toujours depuis la CVM, on check nos interfaces actuelles

On identifie nos interfaces UP et 10Gbs

nutanix@cvm$ manage_ovs show_interfaces

 

 

 

On ajoute nos cartes réseaux UP et 10Gbs à notre Bond0

nutanix@cvm$ manage_ovs –interfaces eth2,eth3 update_uplinks

 

 

 

De retour sur notre host Acropolis en SSH

On contrôle la configuration actuelle de notre bond0

# ovs-appctl bond/show bond0

 

 

 

Configuration réseau des CVM

Les IPs sont poussées lors du déploiement initial via Foundation, il nous reste donc à spécifier le TAG vLAN du réseau CVM

nutanix@cvm$ change_cvm_vlan vlan_id

 

 

 

Étendre le NDFS

 

A la suite de cette procédure votre hôte et CVM doivent être disponible sur le réseau

Il ne vous reste plus qu’à faire un « Expand cluster » sous votre interface Prism.

Sélectionner vos 2 nodes et faire un expand de votre stockage.

 

 

 

 

 

 

 

Share

Présentation des nœuds capacitifs Nutanix NX-6035C « Storage only node» – Partie 1

 

Nutanix-Product-Shot-3

 

 

Partie 1 : Présentation des nœuds capacitifs Nutanix « Storage only node» NX-6035C

Partie 2 : Comment intégrer au NDFS les appliances Nutanix NX-6035C sous Acropolis Hypervisor

 

http://i1.wp.com/myvirtualcloud.net/wp-content/uploads/2015/07/6035cinndfscluster.png?resize=500%2C325

 

Les clusters Nutanix sont constitués de bloc et de nœuds (hyperviseur)

Les nœuds dans un bloc sont livrés avec une capacité CPU, RAM et Disque identique.

Souvent le nerf de la guerre et la RAM et Disque, si vous souhaitez étendre votre cluster avec un espace de stockage plus important. Nutanix offre la possibilité d’acheter des nœuds capacitifs en stockage.

 

Dans la gamme hardware de chez nutanix voir ICI , les appliances NX-6035C « Storage only node» répondent à cette problématique d’étendre son stockage à moindre coups.

Cette appliance est vendu en paires de 2 Nodes pour assurer la résilience, on peut la qualifier de tête NAS avec toute l’intelligence Nutanix derrière (Via une CVM par nœud).

Mais à savoir que ces nodes sont fournis avec Acropolis hypervisor (Custom KVM) et sont intégrés à votre cluster hyper-v ou VMware .

 

Oui oui on mélange les hyperviseurs.

Pourquoi ?

Ces appliances sont vendues pour fournir du stockage et non du compute (RAM / CPU), alors pourquoi devoir les licencier juste pour faire tourner la CVM qui se chargera du partage des données.
Ces nouveaux nœuds ne seront pas vue en tant qu’hyperviseurs, donc économie de licensing de l’éditeur. Mais surtout ces nodes seront intégrés au NDFS cluster (Nutanix Distributed File System) avec accroissement de votre espace de stockage mais aussi IOPS.

 

 

 

 

 

 

Share

HP StoreVirtual VSA – Partie 3 : Enregistrement des licences VSA

 

 

Partie 1 : HP StoreVirtual VSA – Partie 3 : Installation et deploiement sur ESXi

Partie 2 : HP StoreVirtual VSA – Partie 2 : Configuration du cluster VSA

Partie 3 : HP StoreVirtual VSA – Partie 3 : Enregistrement des licences VSA

 

 

Enregistrement de la licence

Le licensing des appliances est particulier donc un petit post présentant la procédure n’est pas du luxe.

 

Il vous faut référencer les MAC adresses de vos VSA et se connecter à son portail HP

Se loguer avec ses ID HP, et accéder à ses contrats

registervsa

 

 

 

Récupérer l’adresse MAC de la première carte Ethernet d’une VSAxx.

 

 

 

L’inscrire sur le portail HP, sous Product Activation

 

Download

Sauvegarder votre clef en local sur votre PC

 

 

Save du fichier DAT

 

 

 

Le fichier DAT une fois téléchargé est à ouvrir avec un éditeur de txt

 

 

 

Copier la clef

 

 

 

Sous le portail de configuration HP StoreVirtual

Sous VSA0X coller la clef qui convient

 

 

 

Edit licence key et coller la clef

 

 

 

Votre VSA est enregistrée

 

 

 

Procédure à faire pour chaque VSA déployées

 

 

 

 

 

 

Share

HP StoreVirtual VSA – Partie 2 : Configuration du cluster VSA

 

 

 

Partie 1 : HP StoreVirtual VSA – Partie 3 : Installation et deploiement sur ESXi

Partie 2 : HP StoreVirtual VSA – Partie 2 : Configuration du cluster VSA

Partie 3 : HP StoreVirtual VSA – Partie 3 : Enregistrement des licences VSA

 

 

Apres l’installation des Appliances VSA sur chacun des ESXi, voici comment créer votre cluster de stockage partagé

 

 

 

 

Ouvrir la management console installé précédemment

 

 

 

On vérifie que nos 3 systèmes sont découverts, sinon redémarrer vos VMs.

Si VM toujours non découverte vérifier votre connexion réseau (Ping,…), si toujours rien supprimer et redéployer le ou les VSA down en CLI.

 

 

 

On débute la configuration via :

Getting Started

 

 

 

On clic sur Management Groups, Clusters,…

 

 

 

New Group

C’est un groupe de management, celui-ci peut contenir plusieurs clusters VSA

 

 

 

 

Création du Groupe de management

 

 

 

Donner un login et MP

 

 

 

Mise à l’heure, idéalement via un NTP

 

 

 

Donner un nom DNS à votre management group

 

 

 

 

Cluster Standard car 1 site

 

 

 

 

Nom du cluster VSA

 

 

 

 

IP virtuel pour la connexion iSCSI

C’est une nouvelle IP à attribuer sur laquelle pointerons les ESX pour la connexion iSCSI

 

 

 

 

Création du volume, nous donnons 1020Go car nous optons pour 2 disques en miroirs.

En effet nous avons donné 1To à chacune des VMs vue qu’elles sont en miroir nous auront 1To de disponible.

 

 

 

 

La création est en cours

 

 

 

 

 

Ajout des serveurs

Une fois le volume créé, nous ajoutons les serveurs (Nos ESXi) qui seront autorisés à se connecter au volume partagé.

 

 

 

 

 

Ajout de l’ESXi 1 puis 2, avec leur ID de l’adaptateur iSCSI des ESXi (Celui-ci se trouve dans les propriétés de la carte iSCSI de l’ESXi)

 

 

 

 

Une fois les ESXi ajoutés, nous autorisons les hyperviseur à se connecter au volume

Sur notre volume clic droit => Assign and Unassign Servers

 

 

 

On sélectionne nos 2 ESXi

 

 

 

Nos 2 ESXi autorisés nous pouvons leur mapper le nouveau volume

Pour plus de détail voir cette article :
 http://vroomblog.com/ajouter-une-lun-a-un-esxi-via-un-adaptateur-iscsi/

Sous chaque ESXi

Faite découvrir le volume via l’IP virtuel

Propriété sur la carte iSCSI

 

 

 

Sous Details un nouveau device doit apparaitre après le RESCAN

 

 

 

 

Ajout du volume

 

 

 

Dernière partie l’enregistrement des Appliances

 

 

Share