vmware felhasználói közösség

Posts Tagged ‘ha’

Előző cikkeimben „szigetszerűen” telepítettem ESX 3.5 vagy ESXi 3.5 kiszolgálókat. Felügyeletükhöz a szerverre kapcsolódva letölthető VI klienst használtuk. Természetesen ez csak a kezdet, az ESX VI környezet előnyeit több fizikai gépből álló fürt (clusa ter) estén tudjuk kamatoztatni. Ehhez azonban egy központi felügyeleti szerver kell telepítenünk, melynek neve Virtual Center. Ez egy Windows 2003 szerverre épülő szoftver, mely egy MS SQL (vagy Oracle) adatbázis háttérrel támogatva az összes ESX/ESXi kiszolgáló együttes felügyeletét ellátja. Ilyenkor a VI kliens nem a fizikai kiszolgálóhoz, hanem a Virtual Center szerverhez kapcsolódik. Ebben a formában már definiálhatunk szerverek közötti kapcsolatokat, úgymint „Adatközpontok/DataCenter” vagy „Fürtök/Cluster”. Az így definiált gépcsoportokon már elérhetőek olyan szolgáltatások is, melyek a folyamatos üzemet támogatják (COS). Ide tartozik a virtuális gépek fizikai kiszolgálók közt történő tervezett mozgatása (VMotion) illetve az erre épülő szolgáltatások úgymint DRS vagy DPM. A magas rendelkezésre állást a 3.5-ös ESX szerverek esetén a HA agent biztosítja, mely nem tervezett esetekben valamely kiszolgáló kiesése esetén a leállt virtuális gépeket a fürtben elérhető szabad kapacitású kiszolgálókon újraindítja. A kiesés ilyenkor az észrevételi idő (15 mp, de állítható) plusz a virtuális gépek újraindítási idejével arányos. Akinek ez nem volna elég, és katasztrófatűrő telephelyek építésén gondolkoznak, ők a VMware SRM-et nézegessék. Egy másik irány a hibatűrő rendszerek világa, vagyis az FT (Fault Tolerance). Jelenleg az ESX 3.5-ben ilyen jellegű támogatás még nem elérhető. Termszetesen továbbra is lehet szoftveres clustering-et alkalmazni a különböző fizikai gépek azonos virtuális hálózatára kapcsolódó virtuális gépei között (DNS, MS Clustering, Linux Clusterek, stb. Lehet próbálkozni Oracle RAC-cal is, működik, de a támogatást ekkor inkább valamely szolgáltató partnertől kérjük, mint közvetlen a RAC gyártójától).

Read the rest of this entry »

Találtam egy rövid checklist-et, amit elő lehet venni ha gond van a HA konfigurálással:

• Check the HOSTNAME entry in /etc/sysconfig/network to the short name
• Check if your FQDN is greater than 30 characters, in which case HA will not configure properly. This is a known bug in VC20 (see KB article 2259).
• Check IP, routing, and DNS for each host.
• Make sure that storage and network are available across the cluster – Ensure that the hosts are not managed directly: perform all host management through VC.
• May want to add nodes to /etc/hosts on ESX Server AND hosts file on VC Server. A better plan would be to use primary and secondary DNS servers.
• Check if Service Console has default gateway defined.
• Verify logs: /opt/LGTOaam512/* and /opt/LGTOaam512/vmsupport/*.
• Check /etc/hosts and /etc/resolv.conf.
• In ESX 3.x the memory reservation is zero, and the limit is “unlimited.” To see this, edit the settings of a virtual machine, click on the Resources tab, and select Memory on the left. To conform to the ESX 3.x defaults, change the settings to a reservation of 0, and check the Unlimited box under limit. After doing this for all virtual machines, edit the settings for the cluster. Disable HA, and then edit the cluser settings again to reenable HA. The current failover capacity should now match the configured capacity.

Gyakori probléma, hogy HA-hoz szükséges Service Console redundancia nincs biztosítva. Azonban még nagyobb gond, ha a redundáns SC hálózat kialakítása nem megfelelő. Sajnos meglehetősen félrevezető és nem túl bőbeszédű a dokumentáció ezzel kapcsolatban.
Hogyan is kell tehát a Service Console redundanciát kialakítani?

Alapvetően két megoldás létezik

1. A meglévő Service Console-hoz tartozó vSwitch-hez adunk legalább két NIC-et
2. Dedikálunk egy kölünálló NIC-et egy új vSwitch-hez, amihez aztán egy második SC hálózatot rendelünk

Látszólag egyszerű a dolog, de mindkét megoldásnak vannak erős követelményei.

Teaming

Az első megoldás tűnik a legegyszerűbbnek, azonban ez a felállás magában foglal egy lehetséges Single-Point-of-Failure, nevezetesen a mögöttes fizikai switch-et. Nyilvánvaló, ha mindkét NIC-et ugyanabba a fizikai switch-be kötjük, akkor az adott switch meghibásodása esetén az egész HA redundacia bedől. Emiatt mindenképpen külön-külön switch-be kell kábeleznünk a két Service Console-t. Azonban! Ez a kettőzés megköveteli, hogy a két fizikai port-on FastPort (Etherchannel) legyen konfigurálva, amely két fizikai switch esetében csak akkor lehetséges, ha a switch-ek STACK-elve vannak, erre pedig nem minden switch képes!!

Még egy SC

A második lehetőségünk, hogy használunk egy meglévő vSwitch-et és ezen alakítunk ki a második Service Console-t. A VMware ajánlása, hogy erre nyugodtan használjuk a meglévő VMotion-VMKernel vswitch-et, ami valóban a legegyszerűbb megoldás. Sajna ezzel is van egy kis bibi… A VMotion hálózattal szemben követelmény, hogy ez egy teljesen izolált fizikai hálózat legyen; a HA-ról pedig tudjuk, hogy erősen kötődik a DNS-hez, így rögtön felmerül a kérdés: az a Service Console hálózat, amely a VMotion hálózatot használja hogy az ördögbe fog tudni a DNS-hez csatlakozni? Szerencsére van megoldás: /etc/hosts.

Tehát ha a VMotion hálózathoz szeretnénk kötni a redundáns SC-t ezt így tehetjük meg:

1. alakítsuk ki a VMotion vSwitch-en a második SC-t és adjunk neki IP a vmotion subnet-ből
2. szerkesszük meg az /etc/hosts állomány és kézzel vegyük fel a HA cluster minden tagjának a VMotion subnet beli IP-címét
3. Bizonyosojunk meg arról, hogy az elsődleges SC-nél konfiguráltunk DNS-t és ellenőrizzük, hogy létezik-e DNS host rekord minden node-hoz (itt terménszetesen a management LAN beli IP címet kell használni)
4. szerkesszük meg az /etc/nsswitch.conf állományt, hogy ez legyen benne.
   hosts: files dns

Ennek hatására a HA cluster mindkét SC irányba képes lesz név szerint elérni a node-okat. Az nsswitch beállítása miatt előszőr a hosts file-ból fog pingelni (ekkor használja a VMotion-re kötött SC-t), és ha ez nem megy, akkor fordul a DNS-hez (mikor is a mgmt lan-hoz kötött SC-t használ).