iOmega StorCenter ix2-200 NFS Share csatolása routeren keresztül Citrix XenServer 6.0 kiszolgálóra
A feladat nem tűnik bonyolultnak, viszont abban a pillanatban, hogy a két eszköz közé egy routert teszünk, máris nem olyan barátságos, hiszen a változó RPC (rpc.mountd, rpc.statd, rpc.rquotad) portokat fixálni kell. Valamint az sem elhanyagolható tényező, hogy a megosztásunk a lehetőségekhez mérten a legbiztonságosabb legyen. Tehát a cikk erre is megpróbál majd kitérni.
NFS Share létrehozása az iOmega StorCenter ix2-200 eszközön:
- Lépjünk be a webfelületre (http://<IPofNAS>)
- Kapcsoljuk be az NFS megosztását (Network -> Protocols ->NFS = ON)
- Hozzunk létre egy új megosztást (Storage -> Shares ->Add a Share)
- Mivel még nem kapcsoltuk be a Security-t emiatt jelenleg az összes megosztás elérhető NFS protokoll segítségével
- Az NFS nagyon sok portot használ, amelyeket random választ ki a port mapper. Ez nekünk nem jó, mert egy cím fordított (NAT) hálózaton keresztül szeretnénk elérhetővé tenni az NFS megosztást. Emiatt kell a portmaper-t átkonfigurálni. Ehhez mindenképp SSH hozzáférésre lesz szükségünk, amelyet már leírtam, hogyan szerezhetünk meg. Ha beléptünk, akkor az 'rpcinfo -p' parancs segítségével állapíthatjuk meg, hogy jelenleg a mely portokon hallgatnak az RPC szolgáltatások, amelyeket át kell állítani.Az átállításhoz az következő parancsok lesznek segítségünkre:
- rpc.mountd -p <port>
- rpc.rquotad -p <port>
- rpc.statd -p <port>Ezzel csak annyi a gond, hogy a következő újraindításig jegyzi meg a beállítást, tehát nem valami életképes a megoldás. Sajnálatos módon, a hivatalos konfigurációs állomány a /etc/sysconfig/nfs nem létezik és ha kézzel létrehozzuk, sem használja a rendszer így másik megoldáshoz kell folyamodnunk. Gondoltam, hogy akkor meglovagolom a rendszerindítást. Először is ezért le kell menteni a parancsokat egy fájlba:
cat <<EOF > /etc/rc.nfs
rpc.mountd -p <port>
rpc.rquotad -p <port>
rpc.statd -p <port>
EOF - Ez az ötletem sem nyert, mert hiába vannak meg a /etc/rc.local és /etc/rc<x>.d/ könyvtárak, akkor sem futott le a rendszerindítás után a parancsom... Csak két megoldást sikerült kitalálnom, amelyek közül az egyik rosszabb mint a másik, de ez van. Nem valami szép megoldás, de legalább működnek. Az első, hogy eltávolítjuk a merevlemezeket és egy linux alapú rendszerre felcsatoljuk, ugyanis az md0 kötet rejti a /mnt/apps könyvtárat, amely tartalmazza a rendszerpartíciót, ahol módosítani kellene a betöltést. De ezt nem tudjuk az iOmega eszközben megtenni, mivel a partíció read only és újracsatolni sem tudjuk, mert device is busy. Ehhez egy leírást itt találtok.Mivel én nem szeretem megbontani az eszközt és piszkálni a rendszer, ami garancia vesztéshez vezethet, így inkább egy másik megoldást kerestem a problémára, ami talán egy picit humánusabb. Újraindítottam a rendszert és megnéztem, hogy mi zajlik le a boot folyamat során. Hátha találok egy olyan állományt, ami később inicializálódik mint az RPC (hiszen csak ezután lehet a portokat átállítani) és az az állomány talán egy szerkeszthető partíción lesz. Ennek megállapításához a '/var/log/messages' állományt használtam. meg is találtam benne, hogy az RPC inicializálódása után az egyetlen folyamat ami elindul még az a stls_all.sh állomány. Ezt meg is kerestem, hol található:
find / -name 'stls_all.sh' 2>/dev/null
Megtaláltam, hogy az otthona a /mnt/system/opt/apps/axis/stls/stls_dist/bin/ könyvtárban leledzik.
Így már gyorsan módosítható is a fájl. Először az állomány legvégén hívtam meg a beállításomat, de rá kellett jönnöm, hogy korábban kilép a szkript, így ott nem hajtódik végre. Emiatt a legelejére betettem, hogy /etc/rc.nfs.
Tehát most már minden rendszerindításnál meghívásra kerül az állományom, és az összes szolgáltatás már fix porton hallgat. Így képes leszek a port-forwarding konfigurálásra a routeren. - Kapcsoljuk be a Security-t hogy tényleg csak azt osszuk meg amit szeretnénk és kontrollálni tudjuk azt, ki férhet hozzá a megosztáshoz. Ehhez navigáljunk a System -> Security felületre és kapcsoljuk be (ON). Adjuk meg az rendszergazdai fiók nevét valamint a jelszavát. Javaslom, hogy a titkosítást is pipáljuk be.
- Hozzunk létre a rendszerünk számára a megfelelő felhasználói accountokat. (Common -> Users)
- A megosztásnál tiltsuk meg a publikus megosztást. Ehhez navigáljunk a Storage -> Shares alá, ahol válasszuk ki a megosztást és az Access Permissions alatt az Everyone user read és write jogán vonjuk meg.
- Engedélyezzük, hogy a megosztáshoz csak és kizárólag a Citrix XenServer férhessen hozzá. Ehhez maradjunk ahol voltunk, csak az Access Permissions alatt található NFS blokkot válasszuk ki. Itt kattintsunk az Add an NFS Rule gombra. A Hostname mezőbe pedig beírható, hogy mely állomásokról engedélyezzük a hozzáférést. A minta lehet IP vagy domain, de akár egy teljes címtartomány, ha <IP>/<MASZK> módban írjuk le. A rendszer elfogadja a teljes 255.255.255.0 maszkot illetve a /24 formát is.
- Opcionális észrevétel, ha több megosztást is használunk, akkor mindenhol tiltsuk le a hozzáférést az Everyone felhasználónak, ugyanis ha az bármelyik megosztás esetében bent marad, akkor az távolról NFS segítségével szabadon felcsatolható. Valamint jelen pillanatban a megosztást lokálisan nem lehet elérni, mert nincs senkinek sem joga hozzá. Így érdemes egy felhasználót / csoportot hozzáadni az Access Permissions alatt, aki lokálisan is képes a Repository-t szerkeszteni.
- Az NFS szervert állítsuk be, hogy minden felhasználót kezeljen vendégként, azaz ne legyen teljes hozzáférése. Ehhez navigáljunk a Network -> Protocols alá, majd az NFS mellett található fogaskerékre kattintsunk, amellyel lekérhető a beállítása (settings). Itt pedig válasszuk ki a 'Treat client users as guest (all_squash)' lehetőséget.
NFS Port-Forwarding konfigurálása routeren:
- Jelentkezz be a routered admin felületén
- Keresd meg a port-forwarding opciót, vagy a portrange-forwarding lehetőséget, ha van
- Állítsd be a portokat:
- 111 TCP & UDP -> IPofNAS (portmap)
- 2049 TCP & UDP -> IPofNAS (NFS)
- TCP & UDP RPC.Mountd -> IPofNAS
- TCP & UDP RPC.Statd-> IPofNAS
- UDP RPC.Rquotad -> IPofNASSzemély szerint javaslom, hogy az RPC portokat 2050-2052 közé állítsd be, mert akkor az NFS portal együtt, mint portrange forwarding lehet beállítani, így 1 db bejegyzéssel leírható, a normális 4db helyett. - Hogy kívülről is hozzá tudjunk férni hálózatunkhoz, szükségünk lesz egy FIX IP címre. Ha ilyet nem tudunk / nek akarunk bérelni a szolgáltatótól, akkor pedig a routeren egy DDNS accountot kell készíteni. Ennek menetét nem írom le, de javaslom a dyndns.org használatát.
NFS Share csatolása a Citrix XenServer 6.0 szerveren:
- Csatlakozzunk a szerverhez / poolhoz a XenCenter segítségével.
- Hozzunk létre egy új Storage-t (Storage tab -> New SR)
- A varázsló segítségével adjuk meg, milyen storage-ot szeretnénk csatolni (ISO Library or NFS VHD)
- Adjunk nevet a megosztásnak.
- Majd a Location résznél a megosztás elérhetőségét kell megadni. Ez két részből áll. Első a szerver elérhetősége IP címmel vagy domain névvel. A második az NFS megosztás elérhetősége a szerveren.
<PublicIPofNAS>:<NFSLocation>
Az IP címet vagy tudjuk, vagy dyndns segítségével naprakészen tartjuk. Az NFS megosztás helyét pedig az iOmega eszköz pontosan megadja, csak navigáljunk a webes felületen a Storage -> Shares alá. Itt válasszuk ki a megosztásunk nevét, majd alatta lesz egy NFS block, amelyre ha kattintunk, előjön a megosztás helye.
Locaton:<NFSLocation> - A megszerzett információkkal sikeresen csatolható az NFS megosztás.
Citrix XenServer 5.6 SP2 frissítése 6.0 kiadásra
Ez a post is a szerver üzemeltetőknek kedvez, de ez van :)
Minap megpróbáltam frissíteni egy Citrix XenServer 5.6 SP2 kiadást a 6.0 verzióra, mondván vannak benne olyan új funkciók amelyeket ki tudnék alkalmazni. Majd amikor elkezdtem keresni a frissítést jöttem rá, hogy ez nem a megszokott töltsd le a .xsupdate állományt, hanem annál egy kicsit bonyolultabb.
Nézzük sorra, mit kell csinálni, hogy te is sikerrel járj:
- Amennyiben csak 1 hostod van, akkor állítsd le vagy hibernáld az összes virtuális gépet. Amennyiben több és pool-ba kapcsoltad őket, akkor a XenMotion elvileg megoldja hogy folyamatosan átkapcsolja egy aktív node-ra a virtuális gépeket ameddig az aktuális host frissít.
- Készíts mentést minden virtuális gépről (biztos ami biztos).
- Töltsd le a XenCenter 6.0 Windows Management Console alkalmazást a www.citrix.com oldalról.
- Csatlakozz a szerverhez vagy pool-hoz, majd a Tools menüpont alól válaszd ki a Rolling Pool Update varázslót.
- Válaszd ki a poolt vagy a hostot.
- Határozd meg a frissítés módját. Ami lehet automatikus vagy manuális. Személy szerint automatikussal végeztem el.
- A következő lapon futtassuk le a tesztet, ha minden rendben van akkor indítható a frissítés. Ha nem akkor a hibaüzenet alapján kezdjük meg az elhárítást. Nálam csak egy patch-et kellett feltelepíteni.
- Adjuk meg a telepítés forrását. Ezt lehet NFS/FTP/HTTP. Gyakorlatilag ez annyit jelent, hogy a XenServer-6.0.0-install-cd.iso lemez tartalmát a korábban említett 3 protokoll segítségével a hálózaton keresztül elérhetővé kell tenni.
- Ha mindent jól csináltunk a szerver sikeresen frissíti magát 6.0 verzióra.
- Ellenőrizzük a szerver verzióját, a General fül alatt található Version details boxban. A XenServer version: 6.0 értéket kell viszontlátni!
Hogyan engedélyezzünk utólagosan Thin Provisioning-et a lokális Storage-on Citrix XenServer 5.5 és 6.0 esetén
Először is szögezzük le, hogy ez az írás nem a webfejlesztéssel kapcsolatos, hanem a virtualizációval. Konkrétan a Citrix által készített XenServer környezethez. A magyarországi kkv-k többsége nem engedheti meg magának, hogy hatalmas szerverparkokat tartson karban, sőt sokszor egy szerveren túl nem tudnak többre beruházni. Tehát az adatokat nem egy külön Storage-ra helyezik, hanem nagy valószínűséggel a szerverben található merevlemezekből készítenek egy tárolót, jó esetben egy RAID5/10 tömbbel. Így ez a kicsinyke leírás főként nekik lesz hasznos, ha elfelejtették volna a thin provisioning-et bekapcsolni.
De mi is ez ha már így szóba került. Alap esetben ha készítünk egy virtuális szervert, akkor annak allokálni kell egy merevlemez kapacitást. Legyen ez mondjuk 10GB. Abban az esetben, ha egy debiant telepítünk fel, akkor kb 1-2 GB helyet használunk fel. Ha pedig egy Windows 7-et, majdnem az egészet. Mindegy melyik történik, alap esetben a 10GB-ot fizikailag lefoglaltuk a tárolóban a virtuális gép számára. Ha kihasználja, ha nem. Ezt nevezzük tick provisioning-nek. Látható, hogy ez csak akkor működik jól, ha pontosan meg tudjuk saccolni mekkora lesz a végső virtuális szerver tárkapacitása.
Ezzel szemben a thin provisioning lehetővé teszi, hogy virtuálisan allokáljuk a 10GB-ot, de a merevlemezből ténylegesen csak a felhasznált 1-2 GB kerüljön lefoglalásra. Ez sokkal gazdaságosabb, mivel ha van egy 2TB-os Storage-om, akkor ezzel a módszerrel nyugodtan ki lehet ajánlani akár több merevlemez kapacitást a virtuális szervereknek, mint amivel rendelkezünk hiszen csak annyit foglalnak a valós tárolón mint amennyi tényleges adatot foglalna. Így nem lesz baj, ha a későbbi igények növekednek egy virtuális gép esetén, mert nem kell a teljes allokációt újragondolni. Természetesen ennek a megoldásnak nem csak előnyei vannak, hanem egy kicsi árnyoldala, hiszen mindig számon kell tartani a szabad és használt kapacitást a szerveren. Ennek van egy minimális Overhead-je. De ez, a kapott előnyökkel szemben minimális. Tehát ha mindenek előtt a performancia számít, akkor használjunk thick provisionong-et, de ha inkább a gazdaságosság a szempont akkor pedig thin provisioning-et.
De ne szaporítsuk a szót, nézzük hogyan kell utólagosan beállítani a thin provisioning-et Citrix XenServer 5.5 esetén, ha ezt a telepítés során elfelejtettük volna.
1) Állítsunk le minden virtuális gépet és készítsünk róluk másolatot.
Ez azért fontos, mert a lokális Storage-ot meg kell szüntetni, így amit rajta tárolunk az elveszik. Emiatt mindenről készítsünk egy mentést, amelyeket a művelet elvégzése után visszamásolhatunk a Storage-ra.
2) Keressük meg, hogy a Storage Repository melyik partíción található.
cat /etc/xensource-inventory | grep "DEFAULT_SR_PHYSDEVS"
DEFAULT_SR_PHYSDEVS='/dev/sda3'
XenServer 6.0 esetén:
fdisk -l utasítással megkeressük melyik device használ LVM kötetet (alapból ilyen lenne)
fdisk -l | grep "LVM" | awk {'print $1'}
/dev/sda3
3) Szerezzük meg az UUID számát a Storage Repository-nak.
xe sr-list type=lvm
uuid ( RO) : 42080775-542e-5ad9-72a6-a3e483dbd880
name-label ( RW): Local storage
name-description ( RW):
host ( RO): xs-tarenz01
type ( RO): lvm
content-type ( RO): user
4) Szerezzük meg a Physical Block Device UUID azonosítóját, amihez az előbb megismert SR UUID-t használjuk fel.
xe pbd-list sr-uuid=42080775-542e-5ad9-72a6-a3e483dbd880
uuid ( RO) : 8e4c6231-2460-7380-c904-150a31c9bd63
host-uuid ( RO): ba3d140c-3de5-499b-b831-7c40d82958a9
sr-uuid ( RO): 42080775-542e-5ad9-72a6-a3e483dbd880
device-config (MRO): device: /dev/disk/by-id/scsi-SATA_Hitachi_HDT7250_VFA100R1C0GKTB-part3
currently-attached ( RO): true
5) Válasszuk le a PBD eszközt a szerverről, így a XenCenter-ben egy felkiáltó jelet kell majd látnunk a Local Storage mellett.
xe pbd-unplug uuid=8e4c6231-2460-7380-c904-150a31c9bd63
6) Semmisítsük meg a Local Storage-t. (Ehhez már a Local SR UUID-t használjuk)
xe sr-destroy uuid=42080775-542e-5ad9-72a6-a3e483dbd880
XenServer 6.0 esetén:
Az sr-destroy utasítás nem működik, mondván VDi merevlemez található a köteten, pedig mindent eltávolítottam. Ezért helyette az sr-forget utasítást használtam.
xe sr-forget uuid=42080775-542e-5ad9-72a6-a3e483dbd880
7) Hozzuk létre a Storage-t újra, csak már Thin Provisioning-el. Ehhez szükség lesz a Host-UUID-re és a Partícióra.
xe sr-create host-uuid=ba3d140c-3de5-499b-b831-7c40d82958a9 content-type=user type=lvm device-config:device=/dev/sda3 shared=false name-label="Local storage" sm-config:allocation=thin
8) Másoljuk vissza a virtuális gépeket, majd ellenőrizzük a tároló kapacitását.
Az eredeti cikk ami alapján ez a leírás is született a xendesktopmaster.com oldalon megtalálható.