vCenter Server Appliance – éles üzemben

Előző cikkeimben bemutatásra került a VMware új, Linux alapú vCenter Server Appliance megoldása, és a vele együtt debütáló egyik új lehetőség: az Auto Deploy. Ezekben a cikkekben megismerkedhettünk az új termékekkel és hozzájuk kapcsolódó szolgáltatásokkal, majd telepítésükkel és alapvető beállításaikkal. Ám mindez csak arra elég, hogy egy teszt rendszeren bemutatható legyen a dolog, valós üzemeltetési tapasztalatot csak éles környezetben lehet szerezni, így mi – vélhetően elsőként – éles üzembe állítottuk az új appliance megoldást.

A következőkben, az élesbe állítás lépeseit fogom bemutatni – a hozzá szükséges egyéb kiegészítésekkel és beállításokkal együtt. Majd – hozzászólások formájában – a használata és üzemeltetése közben szerzett tapasztalataimat fogom megosztani itt.

Előkészületek

Mielőtt nekiesnénk az új vCenter Server telepítésünknek, néhány fontos dolgot tisztázni kell:

Az itt leírtak megértéséhez és alkalmazásához a VCP szintű VMware ismeretek mellett a SUSE Linux rendszergazda szintű ismerete is elengedhetetlen.

Limitációk

Ami persze relatív, de mindenképp említésre érdemes különbségek a ‘megszokott’ windows alapú vCenterhez képest:

• Nem lesz ‘Update Manager’

Ha használjuk az AutoDeploy-t, nem is lesz rá szükségünk többé!

• Nem használhatunk ‘Linked Mode’-ot

Nem tudom ezt ki használta, és mire…. de szerintem a gyakorlatban használhatatlan. Semmi olyat nem nyújt számunkra, amire valóban szükségünk lenne. Amit elvártunk volna tőle, azt meg nem tudja…

• Nem használhatunk ‘vCenter Hertbeat’-ot

Ezt nem tudom ki találta ki, és főleg minek? HA windows-on? Köszönjük, nem kértük eddig sem.

• A ‘vSphere Storage Appliance’ egyelőre nem támogatott

Ez szintén a vSphere 5.0-ban jelent meg, senki nem használta még élesben, nekünk nem is hiányzik, van rendes storage-ünk :)

• Külső adatbázisként csak Oracle használható

A Windows-tól és az MS termékektől igyekszünk szabadulni, így ez annyira nem fáj. – De véleményem szerint egy MySQL is bőven elegendő lenne a feladatra. Kis és közepes (magyarországon csak ilyen van) környezetek esetében pedig megfelelő lehet a beépített DB2 is.

• Migrációra nincs lehetőség

Ez azonban már kicsit fájhat, hiszen újra kell telepíteni a teljes virtuális infrastruktúrát. Emiatt sokkal körültekintőbben kell eljárni, és előre megtervezni az átállás folyamatát. Teljesen új projekt esetén persze ez megint nem hátrány…

Szükséges információk

• Topológia

Hacsak nem egy szigetet tervezünk építeni a semmi közepére, akkor szükségünk van a meglévő hálózatok konkrét topológiájának teljes ismeretére – Ennek hiányában akár  a meglévő hálózat teljes összeomlását is okozhatjuk – amiért nem fognak megdícsérni.

Egy virtuális környezet megfelelően biztonságos tervezése külön feladat, erre nem is térnék ki most, addig is, javaslom az egyik korábbi VMUG-on tartott előadásom anyagát: vSphere-Hardening

A részletes és előzetes tervezés elengedhetetlen egy sikeres projekthez! Ha nem áll rendelkezésünkre saját, megfelelő hozzáértéssel (vmware, hálózat, security) rendelkező csapat, kérje külsős szakemberek segítségét, megéri! Egy ilyen átállás/migráció könnyen kudarcba fulladhat, ha az előzetes tervezést elhanyagoljuk. A tipikus tervezési hiányosságok pedig általában csak később bukkannak elő, amikor már valóban élesben üzemel a virtuális környezetünk. Legtöbb ilyen esetben az utólagos tervezés, és az ennek megfelelő átalakítások sokkal több pénzbe, időbe, és az éles környezet leállásába kerülnek!

• IP cím

Kelleni fog egy IP az új vCenter számára, amit az eddig megszokott elérhetőségeken felül a :22 és a :5480 portokon kell majd az adminisztrátoroknak elérni.

• DNS

Hasznos dolog előre előkészíteni az új gép DNS bejegyzését is, főleg ha ez nem a mi hatáskörünkbe tartozik…

• DHCP

Az Auto Deploy működéséhez szükség lesz arra, hogy az ESX-ek dhcp segítségével kapjanak IP-t, és néhány speciális beállítást. Külső dhcp szerver használata esetén, azt külön fel kell erre készíteni, az appliance saját dhcp szerverének használata esetén ügyelni arra, hogy ez ne okozzon problémát a hálózat többi gépe számára.

• Tanúsítványok

A telepítés során minden SSL-es kapcsolat egy self-signed tanúsítványt kapott, ami miatt a hozzáféréskor ‘SSL warning’-ot kapunk. Ezt sajnálatos módon legtöbben csak ‘ignorálják’, vagy jobb esetben felveszik elfogadott tanúsítványok közé. Az igazi megoldás azonban ezek cseréje, hivatalos – de legalábbis számunkra elfogadott – kiadótól származó tanúsítványokra.

Telepítés

Az appliance telepítése egyszerű, annak alapvető lépései megtalálhatóak itt: vCenter Server Appliance így azt ott leírtakat már nem ismétlem…

Beállítások

Az következőkben azokat a beállításokat, és extra teendőket részletezem, amik éles üzemhez szerintem elengedhetetlenek.

• adatbázis

Jelen esetben a beépített DB2 adatbázist használjuk, amit a management felületen aktiválhatunk.

A jelenlegi legfrissebb verzió még tartalmaz egy hibát, ennek javítását már most tegyük meg, még mielőtt probléma lenne belőle.

• user accountok

Lássuk, milyen aktív felhasználóik léteznek a rendszeren:

vcenter:~ # for user in `grep -v "\:\(*\|\!\)\:" /etc/shadow |cut -d: -f1`; do grep $user /etc/passwd ; done
root:x:0:0:root:/root:/bin/bash
dasusr1:x:1001:108::/opt/db2/home//dasusr1:/bin/false
db2inst1:x:1002:109::/opt/db2/home//db2inst1:/bin/bash
db2fenc1:x:1003:110::/opt/db2/home//db2fenc1:/bin/false
vc:x:1004:100::/opt/db2/home//vc:/bin/false

Az eredményben látható felhasználóknak – számunkra legalábbis – ismeretlen a jelszava, ezek közül is kivastagítottam azokat, akiknek shell-jük is van. A root ugye mi vagyunk, ennek a jelszavát kapásból cseréljük is le!

• ssh

Az imént fény derült rá, hogy vannak felhasználók akik nem a mi kezelésünk alatt állnak, így vegyük elejét a default jelszavak kihasználási lehetőségeinek, és tiltsuk le a jelszavas bejelentkezés lehetőségét! Ehhez először vegyük fel az ssh kulcsunkat a következő – még nem létező – állományba:

vcenter:~ # vim .ssh/authorized_keys

Majd, kapcsoljuk ki a jelszavas bejelentkezés lehetőségét, amit a : /etc/ssh/sshd_config állományban a következő sorral tehetünk meg:

PasswordAuthentication no

És indítsuk újra az érintett szolgáltatást:

vcenter:~ # service sshd restart

Ezek után nagyon hasznos, ha egy új belépéssel teszteljük is a beállítás sikerességét, még mielőtt kilépünk a jelenlegi session-ből…

• ipv6

A VMware hivatalosan nem támogatja az ipv6-ot, ám az appliance alapjául szolgáló linux igen, így ha nem teszünk ellene, akkor minden szolgáltatás figyelni fog ipv6-on is, és akár tudtunk és beleegyezésünk nélkül még  IP címet is felvehet a gépünk – éljen az ipv6!

Ezt, és az ebből következő esetleges problémákat megelőzendő, kikapcsoltam az ipv6 támogatást, ám ez esetben egy csomó szolgáltatás el sem indult – így ez nem jó megoldás, marad a szigorú csomagszűrő.

• csomagszűrő

Alapból nincs csomagszűrő a gépen, ami netstat kimenetét nézve eléggé merész dolog, éles üzembe állítani csomagszűrő nélkül elég nagy hiba lenne – főleg, ha az ajánlásaink ellenére nincs külön fizikailag szeparált management zóna kialakítva a vCenter és az ESX-ek management portjai számára.

Hogy ki milyen módszerrel varázsol csomagszűrőt, az mellékes, de valami ilyesmit kellene elérni:

vcenter:~ # ip6tables -L -n -v
Chain INPUT (policy DROP 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         
    0     0 ACCEPT     all      lo     *       ::/0                 ::/0                
    0     0 LOG        all      *      *       ::/0                 ::/0                LOG flags 0 level 4 prefix `D:INPUT ' 

Chain FORWARD (policy DROP 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         
    0     0 LOG        all      *      *       ::/0                 ::/0                LOG flags 0 level 4 prefix `D:FORWARD '

Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination

vcenter:~ # iptables -L -n
Chain INPUT (policy DROP)
target     prot opt source               destination         
REJECT     tcp  --  0.0.0.0/0            0.0.0.0/0           tcp dpt:113 reject-with icmp-port-unreachable
ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0           tcp dpt:22
ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0           tcp dpt:80
ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0           tcp dpt:443
ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0           tcp dpt:5480
ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0           tcp dpt:514
ACCEPT     udp  --  0.0.0.0/0            0.0.0.0/0           tcp dpt:514
ACCEPT     udp  --  0.0.0.0/0            0.0.0.0/0           tcp dpt:902
ACCEPT     udp  --  0.0.0.0/0            0.0.0.0/0           tcp dpt:6500
ACCEPT     udp  --  0.0.0.0/0            0.0.0.0/0           tcp dpt:6502
LOG        all  --  0.0.0.0/0            0.0.0.0/0           LOG flags 0 level 4 prefix `D:LOdmz '
DROP       all  --  0.0.0.0/0            0.0.0.0/0           

Chain FORWARD (policy DROP)
target     prot opt source               destination         
LOG        all  --  0.0.0.0/0            0.0.0.0/0           LOG flags 0 level 4 prefix `D:FORWARD '
DROP       all  --  0.0.0.0/0            0.0.0.0/0           

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

• ntp

Az alap telepítés esetén ki van kapcsolva az ntp szerviz, és a management felületről sem lehet ntp szervert felvenni, illetve a szolgáltatást elindítani, így használjuk a yast2 konfig szerkesztő izét – amit személy szerint nagyon utálok, de mivel az összes konfig ezzel készült, így mégis ezt használom, nehogy a következő rendszerfrissítésnél probléma legyen belőle.

• log gyűjtés és forgatás

Na, itt van a legnagyobb káosz. Számomra teljesen érthetetlen módon, totálisan bénán van konfigurálva a log forgatás, aminek következtében egy éles rendszeren rengeteg log állomány keletkezik, össze vissza forgatva. Véleményem szerint, az összes logot a következők szerint érdemes forgatni:

daily
rotate 365
create
dateext
compress
delaycompress

A fentieket beállítottam a /etc/logrotate.conf-ban, majd a /etc/logrotate.d/ könyvtár alatt az összes állományból kigyomláltam azokat a sorokat amik a fentieknek ellentmondó volt…

Így, remélhetőleg egységes, és áttekinthető logokat kapunk…

• felügyelet

Egy éles gépet felügyelni kell, hogy az adminisztrátorok időben értesüljenek az esetleges hibákról vagy rendellenességekről. Mi erre Munin-t és Nagios-t használunk, saját kibővített szenzorokkal…

Mindezektől függetlenül, mindenképp hasznos dolog a root felhasználó postaládáját egy létező, és általunk olvasott postafiókra továbbítani. Ezt legegyszerűbben az  /etc/aliases állományban tehetjük meg.

Tanúsítványok

Éles üzemben érdemes hivatalos tanúsítványokat használni, amit beszerezhetünk publikus tanúsítvány kiadóktól vagy,  ha cégünk rendelkezik belső PKI rendszerrel, akkor egy céges tanúsítvány is megfelel. Mindössze egyetlen tanúsítványra lesz szükségünk arra a névre kiállítva, amivel majd a böngészőkből és vSphere kliensből el szeretnénk érni…

Lássuk, pontosan milyen szolgáltatásokhoz is kell SSL tanúsítvány:

:443

Ez a standard https port, azonban a vcenter esetében nem csak egy egyszerű webszerver figyel itt, hiszen tulajdonképpen ide csatlakozunk a vSphere klienssel is. Az appliance esetén a következő állományokban találhatóak a tanúsítványok:

/etc/vmware-vpx/ssl/rui.crt
/etc/vmware-vpx/ssl/rui.key
/etc/vmware-vpx/ssl/rui.pfx

Ezek közül, a .crt, és a .key nem szorul különösebb magyarázatra, azonban a .pfx igen, ugyanis ezt a következő paranccsal kell létrehoznunk:

openssl pkcs12 -export -in rui.crt -inkey rui.key -name rui -passout pass:testpassword -out rui.pfx

Igen, a jelszónak is PONTOSAN így kell kinézni – gondolom, valahol jól bele van drótozva az alkalmazásba…

Hogy használja is a rendszer az új tanúsítványokat, ezeket be is kell tölteni. A hivatalos dokumentáció szerint, nem is mindegy hogy hogyan!

Persze, ez a windows-os verzióról beszél, értelem szerűen kisebb módosításokkal, de követni kell a leírást, majd a végén újraindítani az érintett szolgáltatásokat:

service vmware-vpxd restart

:5480

Ezen a porton érhető el az adminisztrációs felület. Ezt egy igen egyszerű webszerver szolgálja ki, a lighthttpd. Ez alatt a tanúsítványt a következő paranccsal cserélhetjük ki:

cat rui.key rui.crt >/opt/vmware/etc/lighttpd/server.pem

Majd indítsuk újra az érintett szolgáltatást:

service vami-lighttp restart

Természetesen, jogos igény lenne, hogy tovább szigorítsuk a szolgáltatáshoz való hozzáférést, hogy csak a megfelelő kliens tanúsítvánnyal rendelkezőket engedjük kapcsolódni… Ennek beállításához a következőkre lenne szükség:

#### SSL engine
ssl.engine                 = "enable"
ssl.pemfile                = "/opt/vmware/etc/lighttpd/server.pem"
ssl.ca-file                = "/opt/vmware/etc/lighttpd/CA.pem"
ssl.verifyclient.activate  = "enable"
ssl.verifyclient.enforce   = "enable"

Ám ez a verzió – amit várhatóan a VMware saját maga fordított – ezt valamiért mégsem támogatja :(

vcenter:~ # service vami-lighttp restart
Shutting down vami-lighttpd: done.
Starting vami-lighttpd: done.
2011-12-01 12:17:03: (/build/mts/release/bora-471789/vadk/src/vami/apps/lighttpd/1.5.0-2349/src/server.c.1485) WARNING: unknown config-key: ssl.verifyclient.activate (ignored)
2011-12-01 12:17:03: (/build/mts/release/bora-471789/vadk/src/vami/apps/lighttpd/1.5.0-2349/src/server.c.1485) WARNING: unknown config-key: ssl.verifyclient.enforce (ignored)

:9443

Itt lenne elérhető a web client – ám ezt éles környezetben használni igen nagy bátorság. Az előző cikkből kiderülhetett hogy ez egy flash izé, az ígéretekhez képest nagyon kevés implementált fícsörrel. Most még jobban megvizsgálva, az egész egy nagy java-s katyvasz, gyanúsan féligkész megoldások halmazával, amiknél a tanúsítvány cserét sem sikerült végeznem egyelőre… Legjobb, ha csomagszűrőből tiltjuk ehhez a porthoz való hozzáférést!

 Mentés

Mivel ez egy virtuális gép, így mentését megoldhatjuk ugyan úgy, ahogy a többi VM-et is mentjük :)

Persze, sokkal szofisztikáltabb módszereket is alkalmazhatunk, aminek lényege hogy egy default install után a mentéstben szereplő állományokat visszatöltve ismét megkapjuk a jelenlegi, működő allapotot.

Ehhez menteni kell a következőket:

• Adatbázis

Ez egylőre fekete bárány, mivel eddig nem üzemeltettünk DB2 adatbázist, így menteni sem nagyon tudom hogyan kellene – a cél hogy az adatbázis visszaállítható legyebn :)

• Konfigurációs állományok, és tanúsítványok

Ezeknél egyszerűbb a dolgunk, hiszen csak azokat az állományokat kell menteni, amiken változtattunk…

Migráció

Maga a migráció – egy éles környezet estén – a legkritikusabb fázis, ugyanis általában a cél az, hogy a lehető legkisebb leállása vigyük át a virtuális gépeket az új környezetbe. Sokszor az új környezet tulajdonképpen a meglővő vCenter és ESX-ek cseréjét jelenti, így visszaállásra nnics – vagy csak rengeteg munka árán van – lehetőség. Így ehhez a műveletethez mindenképp javasolt hozzáértő szakemberek segítségét kérni.

A feladat összetettsége – és a lehetséges kiinduló állapotok sokfélesége miatt – ehhez konkrét leírást adni nem lehet. Irányadónak a hivatalos dokomentációt javaslom.

Frissítések

Ez egyelőre kényes – és ráadásul ismeretlen terület, mert jelenleg nincs elérhető frissítés. Ám, amint lesz, különösen oda kell arra figyelni, hogy mi lesz a sorsa az általunk kézzel módosított állományoknak!

Összefoglalás

Ahogy az elején is felhívtam erre a figyelmet, az itt leírtak megvalósításához komoly szakértelem kell. Könnyen előfordulhat, hogy valami mégsem úgy működik ahogy leírtam, így csak akkor áljon neki bárki ilyen szintű módosításoknak, ha probléma esetén egyedül is elboldogul. Hivatalos supportot ilyen szintű módosítások után kizárt hogy bárki is nyújtson egy ilyen rendszerre.

Tehát, bármilyen módosítást mindeki csak SAJÁT FELELŐSSÉGRE végezzen!