Virtualizáció proxmox ve 3
Amikor az ipari megoldásokra van szükség, a legegyszerűbb, legegyszerűbb és monolitikus megoldást kell választani ... ami időben tesztelhető. A kísérleti technológiáknak nincs helye. És ami különösen fontos, az emberi tényező mindig nem kis szerepet játszik. a rendszert be kell állítani és meg kell tanítani az embereknek, hogy helyesen használják (esetünkben a rendszergazdák). És itt nagyon fontos, hogy van egy normál felület ezen ügyek kezeléséhez, mert sok a "csupasz" parancssorral egyszerűen megtagadja vagy nem. Szintén nagyon fontosak számos beépített függvény, mint például: a központosított csomópont hiánya (kvórumállapot), a kiszolgálók klaszterezése és az összes kapcsolódó zseton.
Az én esetemben főleg OpenVZ konténereket fognak használni. de általában a KVM virtuálisak nagyobbak a keresletnél, mint a konténerek (mi megpróbáljuk őket a cikk során). De a konténerekről is szeretnék mondani egy szót ... Szeretném használni az LXC-t. ahelyett, hogy a OpenVZ (ami, sőt - az apa), de LXC mindig nincs külön webes felületen (Fork LXC Web Panel on GitHub adnék állapota - kísérleti), és körülbelül csoportosítás és nem beszél ... és amikor a teljes adatközpontot automatizálni kell, hogyan kell nélkülözni? Mi a különbség az OpenVZ és az LXC között? Hmm, igen nagyjából ez ugyanaz, ha nem lép be a kódba. Valójában az egyetlen különbség az, hogy az OpenVZ a 2.6-os kernelt használja (minden biztonsági javítással, friss KVM és tűzifa), és az LXC szerepel az upstreamben, azaz a vanília magban 3.8. óta. És mintha az időben, nyilvánvaló, hogy még erősebb lesz, és "összenyomja" az OpenVZ-t. De abban a pillanatban, részeként OpenVZ Proxmox úgy néz ki, kész és teljes megoldást (Proxmox fejlesztők ígérete egy későbbi kiadásban OpenVZ cserélni a LXC. Ha ezek egyenértékű funkciók).
Egyébként ... ez csodálatos, de a Proxmox-ban a futómintában szinte nem találtam dokumentációt orosz nyelven. Mindez csak a Burujuysky off.dokah és a fórumokon. Tehát ez a kézikönyv nagyon hasznos lehet a nyilvánosság számára :)
Oké, elég demagógia. mentünk telepíteni és konfigurálni a disztribúciónkat a csomópontokon!
A gyakorlat mutatja. a különböző klasztereknek különböző alhálózatokban kell lenniük, hogy ne zavarják egymást (például: egy klaszter az 1.1.1.X-ben, a második az 1.1.2.X-ben, a maszk és az átjáró mindenhol azonos).
A frissítés után ellenőrizze a tényleges helyzetnek való megfelelés dátumát és időpontját.
Ha az idő nem egyezik, javítsa ki (opcionális):
ahol:
MM - hónap
DD - nap
hh - óra
mm - perc
YYYY - év
ss - másodperc
Ezt követően a csomópont konfiguráció teljesnek tekinthető. Állítson be minden más csomópontot, majd egyesítse őket egy fürtbe.
Először létre kell hoznia egy fürtöt az első csomóponton. Ez egyszer megtörténik.
3.1) Klaszter létrehozása
Itt adhatja meg a fürt nevét (a jövőben nem lehet megváltoztatni):
Ellenőrizze a klaszter állapotát:
Ez minden! Ezután hozzá kell adnia a már konfigurált csomópontokat.
3.2) Csomópontok hozzáadása a klaszterhez
Csomópontok hozzáadása a fürtbe, futtassa a parancsot (végre kell hajtania a parancsokat a leginkább hozzáadott csomóponton):
Add hozzá, megkérjük, fogadja el az RSA kulcsot (kérésre be kell írnia a "yes" -t), és be kell írnia a jelszót annak a csomópontnak a gyökérjéhez, amellyel csatlakozunk.
Ellenőrizze a klaszter állapotát:
A gyakorlat mutatja. minden klasztercsomópont a legjobb a megbízhatóságra az összes fürtszerveren az / etc / hosts alatt.
3.3) Csomópont törlése egy fürtből
Ez a tétel külön figyelmet igényel, ha van egy ostobaság - megtörheti a teljes fürtöt. Először el kell távolítanod az összes VM-et a törölt csomópontról (áthelyezni őket egy másik kiszolgálóra vagy törölni). Ezután kapcsolja ki ezt a csomópontot, és fizikailag kapcsolja le a hálózatot (fontos: győződjön meg róla, hogy a jelenlegi állapotában soha többé nem fog megjelenni a hálózaton!)
Ellenőrizze a csomópontok számát:
Mi lesz a csomópont eltávolítása a fürtből? Minden, még több. nincs szükség intézkedésre.
Ellenőrizze újra a csomópontok számát:
Ha vissza kell állítanod ezt a csomópontot a klaszterbe, akkor teljesen újratelepíteni kell a Proxmox + -ot, és új nevet kell adnod neki, és új IP-t kell beillesztened a klaszterbe (lásd a 3.2. Pontot).
A csomópontok konfigurálva és készen állnak, klaszterbe integrálva .... Itt az ideje, hogy csatlakoztassa a boltozatot. Itt egy tipikus példát mutatunk be arról, hogy a tároló közvetlenül a Fiber Channel csatornán keresztül kapcsolódjon a szerverekhez. Az alapkonfiguráció természetesen magában a tárolóban történik. A mi esetünkben ez lesz az IBM Chassis C4A (24 IBM SAS lemezen, amelyek közül 22 integrált a RAID6-ban). Be kell állítani a "szokásos módon" (ez egy külön cikk témája). Miután összekapcsolta a már elkészített csomópontokkal. Az LVM-en keresztül kapcsolódó tárház használatának egyik jellemzője. rá lehet helyezni csak a virtuális KVM lemezeket (és csak formátumban nyersen), de bármilyen módon az OpenVZ konténerek fájljait.
A válasznak így kell lennie:
Egy natív raid körülményei között csak egy lemeznek kell lennie sda1,2,3 ... A kiszolgálónkat egyszerre újraindítjuk. Amikor egy új sdb eszköz jelenik meg az összes kiszolgálón. elindíthatja a diagnosztikát. vagy azonnal csatlakoztassa a tárolót. Az LVM-n keresztül csatlakoztatott külső tárolók csak a VM nyers lemezformátumát használhatják.
4.1) Diagnózis (opcionális)
Leírjuk, hogy érdemes diagnosztizálni, hogy a tároló "hooked" és a rendszer látja. Ez a művelet nem kötelező, végrehajtás esetén elegendő csak egy csomóponton végrehajtani.
A válasznak így kell lennie:
Az újraindítás után ennek a készüléknek sdb-nek kell lennie. Ez a mi raktárunk. Szeretné ezt látni 100% -ban? Oké, menjünk!
Ellenőrizze, hogy a rendszer látja-e a Fibre Channel vezérlőt és a tűzifa van rajta.
A válasznak így kell lennie:
Ez jó. Ezután telepítjük a diagnosztizálni kívánt eszközöket:
Szkennelés új eszközök kereséséhez:
A válasznak így kell lennie:
És most meg vagyunk győződve arról, hogy áruházunk pontosan a sdb betű:
A válasznak így kell lennie:
Ellenőrizzük újra, és győződjünk meg róla, hogy minden a helyén van.
Ezzel befejeződik a diagnózis. Elindíthatja az LVM létrehozását és a Proxmox VE csatlakoztatását.
4.2) LVM létrehozása
Az LVM egy különleges tárolási technológia a Linuxban, melynek köszönhetően képes leszünk élő gépek migrálását a csomópontról csomópontra. Összességében ez úgy működik, mint a VMware vMotion. A konfiguráció nagyon egyszerű :) Minden pont csak egyszer történik, amikor a tároló kezdetben a klaszterhez csatlakozik.
A sdb hangerőt LVM eszközként jelöljük (különös figyelmet fordítva az adatvesztés veszélyére az sdb-nál. Világosan meg kell értened, mit csinálsz ...):
Hozzon létre egy csoportot az "ibm" nevű sdb eszközön:
Ez minden! Minden beállítás automatikusan szinkronizálódik a teljes fürttel. Ezután csak menj a webes felületre, és "rögzítsd" az LVM-t.
Datacenter >>> Tárolás >>> Add >> LVM a "Volume Group" oszlopban válassza az ibm parancsot.
Ez minden! A tároló sikeresen hozzá lett adva és frissítve van a megadott csomópontokon.
Multipath - az adattárolási hálózat csomópontjainak összekapcsolásának technológiája több útvonalon keresztül. Konfigurációnkban 2 FC-t használunk a kiszolgáló oldalon + 2 FC vezérlő a tároló szerver oldalán + SAN-kapcsoló. Összességében kiderül, hogy a bolt 4 csatornán látható. A tároló többszörös útján történő összekapcsolása csatornaváltozást és redundanciát biztosít a rendszer alapvető szintjén. Ez növeli a sebességet, és hiba esetén - a felhasználó számára észrevétlenül további használ. csatornákat. Hogy érted, maga a technológia része a Linux kernelnek, és a legtöbb esetben (a normál hardveren) a teljes konfiguráció automatikusan meghatározásra kerül. Szóval telepítsük:
Végezze el a diagnózist, amint azt a 4.1 pont mutatja. Az egyes lemezek azonosítóját a következő paranccsal ellenőrizheti:
A mi esetünkben a konfiguráció automatikusan meg van határozva. Az általános képünk ez (ha csak egy tárolót csatlakoztatunk a SAN-kapcsolóhoz):
sdb, sdc, sdd, sde - a repository és a 4-csatornás csatornák.
Megvizsgáljuk, hogy a több útvonalat automatikusan definiáljuk:
A teljes körű információ megjelenik a parancs által:
Amint láthatjuk, a tárhelyet 4 csatorna csatlakoztatja. De a legfontosabb paraméter id: 360080e50003e2c4c000003b555000a25, és további: dm-2 (ez az ideiglenes tárolási név). Tehát be van építve a rendszerbe, akkor automatikusan minden esetben azonosítóval, és a név, amire szükségünk van az LVM létrehozásához a 4.2 fejezetben.
Ezen a néven LVM-t hozunk létre:
Ez minden! Továbbá a bolt továbbra is aktiválódik a webes felületen keresztül, amint azt a fentiekben már bemutattuk.
Ez talán a legnehezebb rész. Alapértelmezés szerint a VM-ek klasszikus üzemmódban működnek: a kiszolgálón vannak tárolva, de ha a kiszolgáló nem érhető el, akkor az összes VM nem érhető el vele. Ugyanabban a HA módban a következő történik: szerverhiba esetén az összes VM automatikusan átkerül a fürt másik kiszolgálójára / szervereire. A HA egyszerűen konfigurálható a webes grafikus felületen keresztül. Azonban az egyik követelmény a munka HA (amellett, hogy a high-end gépek és megosztás tárolás) a rendelkezésre álló hardver Vívás Készülék az egyes szerver (ami megakadályozza az egyidejű hozzáférést VM hibás adatokat több szerver, ez az úgynevezett «agyhasítás állapotban» és hozhat az "adat korrupció"). Ez az, ami a Vívásról szól. csalóként működik - fizikailag blokkolja a kiszolgáló hozzáférését a VM-adatokhoz (bezárja a SAN portokat, leválasztja a hálózatot vagy áramellátást, vagy egyszerűen újraindítja a kiszolgálót). Hardware Fencing - a leghatékonyabb és stabil megoldás. Ilyen eszközök például: APC folyók, SAN kapcsolók. és a HP iLO hasonlóságára vonatkozó szolgáltatásokat. Esetünkben a HP ILO segédprogramot használjuk. amely beépül a HP DL360 Gen9 szerverbe. Ideális ez a szerep. Csatlakoztassa és konfigurálja az iLO-t a kiszolgálón, rendeljen hozzá jelszót és konfigurálja a hozzáférést. Miután folytatjuk:
6.1) Vívás
A konfiguráció teljes egészében a konzolon keresztül történik, és konfigurálódik. Erkölcsileg készítsd el. Továbbá, minden Vívóberendezésnek megvan a maga saját konfigurációja. Először aktiválnia kell a Fencing-domain szoftvert, és be kell illesztenie az összes fürtkiszolgálót (hajtsa végre ezeket a műveleteket minden kiszolgálón). Ehhez el kell távolítania a vonalat (FENCE_JOIN = "yes") ebben a konfigurációban:
Ellenőrizze és adja hozzá a kiszolgálót a Fencing-domainhez:
Ezt követően a szerver elveszítheti a szinkronizációt a fürttel. Most újra kell indítani a fő szolgáltatás:
Ezután telepítse az eszközöket a HP iLO használatához az operációs rendszertől az IPMI interfész segítségével:
A szolgáltatás indítása és újraindítása:
Nyilvánvaló, hogy meg fog esni ... az IPMI működéséhez szükség van a rendszermag további moduljainak aktiválására:
Győződjön meg róla, hogy automatikusan újraindulnak az operációs rendszer újraindítása után (javítsa ki a beállítást, és illessze be a következő értékeket):
Az első esetben az ipmidev eszköz megjelenik, a második esetben a kimenet így fog kinézni:
Vívás ellenőrzése. Ezek a parancsok nagyjából ugyanazt teszik (1-2 ellenőrizni az állapotot, 3 - küldeni az újraindításhoz ... bejelentkezés és jelszó az iLO-ból):
Annak érdekében, hogy ne szúrja be a jelszót a konfigurációban (beleértve a webes grafikus felületet is), a legegyszerűbb szkriptet írjuk:
Mindezek után ezeket a műveleteket a klaszter összes kiszolgálóján végezzük el - a legfontosabb és legfontosabb dologhoz jutunk ... a fürt fő konfigurációjának szerkesztéséhez. Óvatosan és óvatosan kell eljárnunk. Ne feledje, hogy a konfiguráció minden módosítása után szükség van rá, és növeli annak verziószámát 1-tel (paraméter config_version = ..). Hozzon létre egy új ideiglenes beállítást:
Itt van a teljesen működő fürt konfiguráció "fürt", amit kézzel írtam: cluster_test1_ilo4
Ez így néz ki:
És most ellenõrizzük a Vívó eszköz munkáját (bármely fürtszerverrõl), és elküldi ezt a csomópontot az újraindításhoz:
Ez minden! Több szerkesztési konfiguráció nem szükséges, minden további műveletet a webes grafikus felületen keresztül kell végrehajtani.
A HA szolgáltatásnak minden egyes VM számára engedélyezettnek kell lennie. Vigyázat: győződjön meg arról, hogy a VM ki van kapcsolva, mielőtt bekapcsolná a HA-t.
Ez a VM nélküli státusz:
VM hozzáadása a HA-hoz:
Új VM státusz HA-val:
Ez minden! Ne felejtsd el új VM-ket csatlakoztatni a HA-hoz.
Ha nincs tároló, akkor a kiszolgálók továbbra is a fürt részét képezhetik - csak így fogják használni csak a lemez alrendszerüket. Előnyük az, hogy az ilyen kiszolgálók OpenVZ konténerekként használhatók. és virtuális gépek KVM. A virtuális gépi lemezek több formátumban is megtalálhatók. A lemezformátumok jellemzői:
- a legjobb teljesítmény
- fenntartja a virtuális lejátszó helyét (rögzített lemez)
- a pillanatkép elkészítésének képessége (beleértve az "élő" -t is)
- fenntartja a helyet a virtuális NEM teljesen (dinamikus lemez)
- Teljes kompatibilitás a VMware programmal
- fenntartja a helyet a virtuális NEM teljesen (dinamikus lemez)
Az OpenVZ konténerfájlok a nagyon csomóponton vannak tárolva: / var / lib / vz / private / ID (ahol a id a coneiner azonosítója a webes felületen)
Röviden. a konténerek használata ajánlott, ha olyan csomópontról van szó, amelyhez nem tartozik hozzá a tárolt tárhely és egy vendég linux rendszer. Hatalmas erőforrás-megtakarítás + lemez / memória bővítés "menet közben."
A konténerbe való belépéshez parancsot kell végrehajtania a csomópontból (ahol 109 a virtuális gép azonosítója):
Mindent, majd testreszabhatja az operációs rendszert, amire szüksége van, telepítse az összes szoftvert (mindent a szokásos módon a virtuálisan). Amikor teljesen konfigurálod a konténert, készítsünk el egy sablont ... ebből a sablonból még egy rakás konténert is fel lehet építeni. Mielőtt folytatná, kattintson a Shutdown (Kikapcsolás) gombra a webes felületen, és tegye ki teljesen a szükséges tartályt. Ezután a webes felületen teljesen törölje a tartály hálózati felületét:
A vonal végén lévő pont fontos, ne érjen hozzá!
Minden, a konténerek új sablonja készen áll a munkára. A Proxmox webes felületén megjelenik.
A kizsákmányolás folyamán nincs kérdés, minden nagyon logikus és intuitív. Amikor bejelentkezel a rendszerbe, akkor akár oroszul is beillesztheted az interfészt. A rendszer támogatja az élő áttelepítést és az élő biztonsági másolatokat, így a virtuális gépek szabadon mozgathatók a bekapcsolt állapotban lévő csomópontok között. A rendszereloszlást az .iso helyi tárolóba betöltheti a helyi csomópontokba - ezáltal kényelmesebbé teszi az új virtuális gépek létrehozását.
Élvezd!)