Magas rendelkezésre állású szerver infrastruktúra ötletek

Virtualizáció

Sziasztok,

Ötleteket, tapasztalatokat várnék a következő feladat megvalósításához.

Amit szeretnék:
- 4 db különböző OS-t futtatni (Windows, Linux vegyesen)
- Ezek alá olyan vasat/szoftvert, amely a lehető legmagasabb redundanciát biztosítja

Elképzelés:
- Szoftver: Vmware ingyenes ESXi
- HW: 2 db szerver + 1 db storage 5 db HDD (raid 10 + 1 db hot spare )

A gondom, hogy 1 milliós keretből én nem találtam olyan megoldást, amely minden pontján biztosítana redundanciát hiba esetén. Elsősorban a storage meghibásodástól tartok, mivel az SMB kategóriában nem találtam NBD garanciát.

Eddig ez a megoldás tetszik a legjobban, de ha elpukkan a storage (ami nem tudom mennyire jellemző), akkor ki tudja hány nap a garancia.
http://www.qnap.com/i/en/product/model.php?II=124

Tehát ha valaki csinált már hasonlót és van ötlete HW és SW vonalon, akkor azt köszönettel elfogadnám!

  • 5442 megtekintés

( newman | 2014. 12. 09., k – 12:53 )

Szia,

egyrészről a keret lesz a szűk keresztmetszet, ha ezt megadod akkor annak megfelelően lehet a legoptimálisabb megoldást kialakítáani. Másrészt virt cluster ne legyen 2 node-os, ajánlott min. a 3 node. (bár ha 2 nodera sincs megfelelő keret...)

( zeller | 2014. 12. 09., k – 13:09 )

Ennyiből nem fogod összerakni. Az NBD garanciára egy példa, aztán eldöntöd, hogy elég-e neked... Csütörtökön késő este eldől egy eszköz, amiről bejelented a hibát, de a hibajegy pénteken 00:01-kor lesz rögzítve. Az NBD szolgáltatásban hétfőn elég megkezdeni a hiba vizsgálatát, de hogy mikor lesz működő motyód, az nem definiált.
Ilyen körben én két izmos szerverrel (dupla hot swap táp, hot swap hűtés és diszk), és Ganeti-vel kezdenék tervezni. (Az általad nézett NAS doboz vezérlőt tekintve nem HA, illetve csak annyira az, hogy HA működik a vezérlő, akkor eléred az adatokat :-P)
A diszkeket pedig nem darab és méret (kevés nagy diszk), hanem IOPS alapján számolgatnám, inkább fele méret dupla darabszám, mert az teljesítményben is, és rebuld időben is jobb.

Ja, és az ESXi is kevés lesz a normális HA-hoz...

+1, meg az a nagy rakat egyéb dolog, ami itt még felmerült. HA-hoz sok dolgot kell SPOF-mentesen megoldani - például a DRBD szinkronizálására szolgáló hálózati kapcsolat minimum két, fizikailag független hálózati kártya bonding-ban összefogott lábait használja, direktben összekábelezve a két szervert, ugyanígy a 230V-os tápot is illik két független UPS-ből megoldani - ha nem megy (1M-ból nem fog...), akkor legalább az egyiket UPS-re kell kötni, ugyanígy a "külvilág" felé hálózati kapcsolatot biztosító eszközöket (kettő darab kell belőlük) illik úgy összerakni/összemakramézni/konfigurálni, hogy bármelyik kiesésénél a másik átvegye a forgalmat...

És persze tesztelni, tesztelni, tesztelni, az éles üzemnél meg backup, backup, backup... :-)

Mentés (másik telephely földrajzilag távol egymástól) és monitoring (Nagios és email az érintettnek) most is megoldott, csak éppen Atom-os noname gépeken fut Ubuntun meg Windows (mondjuk 5 éve HW és SW hiba nélkül - csak HDD csere volt a SW raid-ben) ezt szeretném kicsit redundánsabban megoldani. Erről szólna ez a bejegyzés...

Egyébként köszönöm az észrevételt, akár hasznos is lehetett volna

( dap | 2014. 12. 09., k – 13:36 )

Pacemaker, DRBD, KVM. A HW-be ECC RAM és IPMI LAN menedzsment (STONITH-hoz).

Proxmox?

( junior013 | 2014. 12. 09., k – 14:05 )

Ingyenes ESXi-vel nem megy az automatikus HA, Live migration.
Mai ismereteimmel én adattárolásra egy Ceph clustert húznék fel min. 3 node-ból (akár olcsó, "kommersz" HW-ből) és ezek elé tennék 2 KVM HOST-ot (ezek alá azért inkább brand szerver vasakat)

( _ventura_ v | 2014. 12. 09., k – 14:12 )

2db xenserver + alá valamilyen tároló (iSCSI/NFS) redundánsan.

Fedora 21, Thinkpad x220

( janoszen v | 2014. 12. 09., k – 14:13 )

Ennyi penzbol velemenyem szerint ne HA megoldast akarj epiteni, hanem epits egy tisztesseges hardverbol jol osszerakott szervert jo disk alrendszerrel, a tobbit meg koltsd normalis backupra.

--
Pásztor János
Üzemeltető Macik

-1
Mar maga a 2db tisztesseges szerver is kerdeses kijon-e ennyibol, bar ha kevesebb teljesitmennyel es egy gepen belul kevesebb redundanciaval is beeri akkor meg kijohet, ez inkabb csak annak a kerdese csak ki mit nevez tisztesseges szervernek.
Viszont tisztesseges HA-t sose tudsz csinalni 2 node-bol, csak szerencses esetben latszolag tisztesseges lehet, bar virtualizacio eseten 2 node-al tobbnyire csak akkor tudsz elfogadhato HA-t csinalni ha az a vm amit futtani akarsz kozel statikus es nem kell gyakran modositani, boviteni, uj vm-eket hozzaadni.

Ne vedd bántásnak, de jobb lett volna ezt a postot nem megejteni. A STONITH csak egy fajta fencing, konkrétan node fencing, amit így ahogy leírtad, tilos használni. A STONITH mellé kötelező a quorum, azaz a 3 node (nem, a router mit ping host nem jó quorum résztvevő), különben a két gép egymást lövi ki. Ez a hibahelyzet ugyanis pont akkor fordul elő, amikor a legkevésbé kellene, pl amikor a terhelés alatt, vagy egyéb okból belassul a hálózat és mindkét gép azt gondolja, hogy a másik meghibásodott.

A fencing adott esetben lehet SCSI 3 PR is (resource fencing), amely esetben a közös storage (ami egyébként SPOF) zárolásával kerül biztosításra a konzisztencia. Ez esetben azonban nincs garancia arra, hogy nem egy melléviselkedő node fogja az erőforrást, azaz a quorum + node fencing (aka STONOTH) használata itt is javasolt.

Az adott pénzügyi keretek mellett az eredeti posternek erősen javasolt a manuális failover vagy hot spare használata, kötelező érvényűen backuppal. Különösen mivel nincs a cluster építésben gyakorlata.

--
Pásztor János
Üzemeltető Macik

Ha az egyik STONITH-ol, a másik már senkit nem fog kilőni, mert halott. Egy marad.

Egyébként az a cluster (üzemeltető) hibája ha előállhat olyan helyzet amikor két működö gép azt gondolja egymásról, hogy a másik halott. A STONITH persze ezt is meg fogja oldani, de ez egy elkerülhető failover lenne, így hiba meglépni.

Persze tudom, hogy a STONITH csak egy a fencing megoldások közül, de épp az az egy, ami az általam javasolt setuphoz kell és elegendő.

Rossz tapasztalatok alapján ítélsz.

Ő bocsi, de ha a két gép nem látja egymást, akkor egyszerre fognak STONITHolni, az IPMI lelövésnek pedig van átfutási ideje. Nem olyan bonyolult ilyet előidézni. Ez le is van írva elég világosan a mindenféle HA howtokban. Kérdezz meg egy hálózati szakembert, hány féle képpen romolhat el két gép között a hálózat. A HA-ra pont akkor van szükség, amikor probléma van a gépen és ha pont akkor oroszrulettezik az ember, akkor nem sok értelme volt. Elég sok és változatos méretű clustert láttam már összeborulni. Ha neked mázlid volt eddig, akkor tök jó, de sok-sok rossz tapasztalat mondatja velem, hogy quorum nélkül nem akarsz automatikus failovert vagy stonithot.

--
Pásztor János
Üzemeltető Macik

1. "Egyébként az a cluster (üzemeltető) hibája ha előállhat olyan helyzet amikor két működö gép azt gondolja egymásról, hogy a másik halott." - ez akkor is tény marad, ha a hálózatok sokféleképpen tudnak összeborulni. Opció a tripla redundancia, de nem opció az, hogy redundánsnak nevezünk valamit ami valójában nem az.

Egy átlagos Intel alapú szerveren kb 50-100ms az az időablak amikor ténylegesen megtörténhet amit mondassz és szinte kizárt, hogy a Pacemaker pontosan egy időben triggerelje a STONITH-t (merőben eltérő állapotok). De oké, nagyon paradnoid vagyok, az egyik node-on a STONITH scriptbe beteszem hogy sleep 5 - megoldva?

Továbbra is azt állítom, hogy ez egy hibás prekoncepció.

A deathmatch-hez kell az, hogy:
- megszakadjon a redundáns kommunikáció (ami lehet duplán, triplán redundáns) és
- a STONITH action a reboot legyen, azaz a passzív node feljöjjön a STONITH után úgy, hogy még mindig nem látja a párját.

Az első pontnál egy (többszörösen) redundáns rendszer meghibásodásáról van szó, ami eleve nem lehet gyakori (ellentétben azzal, amikor az üzemeltető azt hitte, hogy redundáns az elem).
A második pontnál pedig felmerül, hogy az üzemeltető miért nem halt-ra állította a STONITH action-t amivel megelőzhető az egész?

Szóval a deathmatch egyáltalán nem elkerülhetetlen, csak egy újabb buktató, de azt senki nem állítja, hogy clustert építeni gyerekjáték.

(A fenti STONITH delay/timeout nem a klasszikus deathmatch ellen van, hanem egy valószerűtlen esemény ellen, nem hiszem, hogy bárki foglalkozna vele, mert nulla közeli az esély arra, hogy bekövetkezzen.)

Sokeves Red Hat cluster uzemeltetesi tapasztalat utan ezzel a megoldassal (egyik node kap egy delay-t a fencing-nel) futtatjuk a 2 node-os clustereket, a Red Hat cluster specialists team ajanlasaval. Nem javasoltak a quorum hasznalatat, mivel a legtobb esetben emiatt dolt a cluster. (mi quorum diszket hasznaltunk ezelott)

Annyi meg hozza, hogy redundant switchable PDU-t hasznalunk fencing-re, szoval power cut van a lassabb node-nak. IPMI nem javasolt production-be legalabbis a Red Hat altal. Mi lattunk mar olyat, hogy amikor kellett volna nem lehetett csatlakozni hozza. Akkor jott az otlet, hogy monitorozni kellene, amitol meg random idonkent bedolt...

Azt ugye nem győzöm elégszer leírni, hogy ebben a felállásban a STONITH race lehetősége eleve csak egy súlyos hiba után merülhet fel, amikor egy redundáns rendszer (hálózat a node-ok között) már kudarcot vallott.

Az IPMI egyes lapokon néha tényleg hajlamos meghalni, de a Pacemaker a STONITH erőforrásokat is monitorozza, ez hamar kibukik. Csak akkor okozhat galibát ha nincs monitoring és az üzemeltető nem veszi észre a befagyott IPMI-t.
Egyébként a napi automata IPMI restart (crontab) itt megoldotta a gondot minden típusú szerveren.

"hány féle képpen romolhat el két gép között a hálózat" - jobb körökben soros port, nullmodem kábel is használatos heartbeat átvitelére, kihagyva a teljes hálózati stacket. Egy ilyen kapcsolat csak akkor döglik meg, ha a soros port fizikailag elpukkan, vagy kitépik a soros kábelt a gépből. Az meg csavarozva van :-P

"Egyébként az a cluster (üzemeltető) hibája ha előállhat olyan helyzet amikor két működö gép azt gondolja egymásról, hogy a másik halott"

Nem, ezt hivjak split brain-nek, ami 2 node-os kornyezetben allhat elo mivel nincs quorum.
Es igen ahogy a kollega is mondta, kulon fejezetek vannak ezt ecsetelve cluster tervezeseknel, hogy milyen kockazatokkal jar, illetve ha mindenkepp akarod akkor mit kell atallitani 2 node-os clusterre. Kulonfele okai lehetnek annak ha eloall, ha eddig teged elkerult akkor szerencsed van, de amikor bekovetkezik nagyon nem fogsz orulni neki, hogy nem csak az van hogy megallt az egyik gep de mindketto mert egymast rantottak a melybe, szerencses esetben nem lesz tole inkonzisztens adatod.

Pontosan tudom mi a split-brain, amit a quorum MELLETT a STONITH is megelőz, hiszen MINDENKÉPP csak 1 node maradhat talpon (vagy janoszen nem túl életszerű szkenáriójában egy se). A split-brain ígyis-úgyis kizárt.

A split-brain -re a megoldás a fencing, a STONITH pedig egy fencing megoldás. Ha a split-brain fellép, akkor az a cluster fencing (üzemeltető) hibája.

Akkor nem az üzemeltető hibája, amikor technikailag képtelenség megoldani a fencing-et - ez előfordul, különösen multi-site setupnál. Jelen eset nem ilyen.

Lehet, hogy en vagyok nagyon szerencsetlen, de tobb, a nagykonyv szerint osszerakott clustert lattam mar csunyan osszeborulni. Az egyiknek en voltam az okozoja, mert a cluster egyik gepe alatti gepet rackeltem ki es a cluster szerverebe bedugott, mar kisse viseltes UTP meglazult es ettol packet lossolni kezdett egyszerre minden.

Elméletben igazad van, a gyakorlatban viszont csomó olyan tényező van, ami nem all az iranyitasod alatt: szoftver bugok a HA stackedben, szoftver bugok a switchekben, csoportosan, időzítve fellépő szoftverbugok a switchekben, betelő mindenfele tablak a switchekben, hibas, megviselt kábelek, figyelmetlen kolléga. Ezekre az esetekre kell a quorum, kivédeni a bökkenőket. Különben mire alkották volna meg egyáltalán a quorum fogalmát?

De tegyünk félre egy pillanatra minden érvet és ellenérvet: szerinted, egy szemmel láthatólag kezdő cluster építőnek az a jó tanács, hogy "jó lesz az úgy, csináld csak!"? Nem kellene felhívni a figyelmét a veszélyekre?

--
Pásztor János
Üzemeltető Macik

Ha egy darab ethernet madzag kirántására az a reakció, hogy a cluster összef0ssa magát, az nem a nagykönyv szerint összerakott fürt, hanem valami, ami majdnem az, de mégsem - SPOF volt az adott kábeles összeköttetés, ami HA-rendszer építésénél nem igazán engedhető meg, hogy finoman fogalmazzak.

Erted ugye, hogy csak pelda volt hogy mennyi fele keppen tudja egy rajtad kivulallo hibaforras elrontani a delutanodat? Az _alatta_ levo gep kirackelesevel sikerult meglazitanom az adott gepben levo X kabelt. Nem tudom, pontosan mi volt, de aki azt a clustert osszerakta, nem ma kezdte. Ott meg arra is figyelve volt, hogy a gepek kulonbozo rackekben legyenek.

--
Pásztor János
Üzemeltető Macik

Értem, persze, de attól, hogy "nem ma kezdte", szépen bent hagyott a rendszerben egy olyan hibalehetőséget, ami nem igazán engedhető meg. A SPOF alattomos dolog - emiatt egy jó HA-megoldás tervezéséhez és összerakásához baromira negatívan kell gondolkozni, a fő vezérfonal a "mi az, ami elromolhat még?" kell legyen. Sok meló, meg sok szívás, de amit ki lehet húzni véletlen vagy szándékosan, azt a tesztek során ki kell húzni :-P

De a quorum se megoldás mindenre, csak egy újabb lehetőség amit lehet jól és rosszul használni. Az adott setup-ban a quorum egyszerűen fölösleges, nincs olyan életszerű szkenárió amikor segítene, a STONITH és a redundáns hálózat alapkövetelmény marad a quorum mellett is, akkor meg minek bonyolítani..?

Szakértelem híjjan egy quorum-os cluster is össze fog dőlni az üzemeltető kezében, a fenti setup semmivel nem lesz biztonságosabb quorummal, csak bonyolultabb.

Egyébként már az elején említettem, hogy ha nem ért hozzá, akkor ne csinálja. Viszont a lehetőségekre szeretem felhívni a figyelmet, mert az adott eszközökkel megoldható a robusztus HA, nem elméletben, hanem tényleg. Aztán majd ő eldönti.

Pl vesz cloud tárhelyet havidíjba, fillérekért. A hosting cégek néha kínálnak valamennyi backup tárhelyet a hosting szolgáltatás mellé, a 2 szerverhez lehet jár annyi, hogy az elég. Nem volt kérdés, ergo ezt ő megoldja valahogy.

Teljesen más performanciával kell bírnia egy mentésre kihegyezett rendszernek. Ott a válaszidők nagysága illetve szórása kevésbé lényeges, míg egy, a felhasználók által "nyomkodott" rendszernél meg ez igencsak releváns infó. Nagyon nem mindegy az sem, hogy mennyi CPU-ra, memóriára van szükség a futó rendszereknél - egy mentőszerverbe jóval kevesebb is elég lehet, ha kellően nagy a mentési időablak. Virtualizációnál, illetve ha van használható snapshot-megoldás, akkor szinte csak a tárhely mérete szab határt a mentésnek. Ha a tárhelyen megvan a megfelelő redundancia, és nem kell offline/offsite mentés, akkor akár diszken tartott snapshot-tal is meg lehet oldani.

+1 Ennyiből csak barkácsolni lehet. Jobb rendelkezésre állást érsz el egy darab minőségi eszközzel, már ha az egyáltalán kijön ennyiből.

Ha kijön két eszköz valahogy akkor Windwos server 2012 R2 valamelyik verziója lesz a megoldás.

Tárolót ennyiért nem meszel, szoftvert főleg nem, rendes szerver megint nem. Ha barkácsolsz akkor az jobban visszaüt mintha egyszer rendesen csinálod meg.

Azt honnan tudod vaktába hogy összehányt? A CEPH mitől nem összehányt?

Szerinted nincsenek guideline-ok, minták, bejáratott eljárások a DRBD es KVM/libvirtd clusteres futtatásához? Hát igen, én is meg lennék lepve ha valaha próbálkozott volna bárki ezeket clusteren futtatni, nem arra valók, tán nem is lehet! ;)

miert lenne szerinted a ceph osszehanyt? erre van tervezve a legelejetol.

a drbd+stonithal az a gondom, hogy ket geppel csinalni barmilyen fele al-HA megoldast lehet csak. tanulni jo, eles adatokat viszont nem biztos, hogy rabiznek.

manual failover mellett mar mukodik a dolog, hiszen az adatok megvannak, ilyenkor csupan a rendelkezesreallas a kerdes, illetve hogy mekkora kiesest toleral az uzleti oldal

Miért, a DRBD nem arra van tervezve hogy 2 node-os HA clustert építs vele? A posztoló nem épp 2 node-os HA clustert akar építeni?

Régen volt egy ügyfelünk aki DRBD-t akart SAN helyett, hosszú vitáim voltak vele, hogy felejtse el azt a gány szart, bár a szakmai érvek helyett tulajdonképpen csak azt matráztam, hogy fostalicska. Odáig fajult, hogy összeraktam egy DRBD clustert hogy majd jól megmutatom neki, hogy annál még a floppy-s tárolás biztonságosabb. Sok munkát beleöltem és kiderült, hogy tévedtem. Amit tud, azt jól tudja. Ettől még nem ez az Ultimate Eszköz, megvannak a korlátai. A korlátain belül viszont remek.

Érteni kell hozzá, ez tény. Gányolni nem kell, minden gyárilag adott hozzá, a know-how is. A megszerzett tudás nagy része minden cluster építésénél felhasználható, konvertibilis.

BTW a Ceph szerintem a legnagyobb királyság, csak a nézőpontodra voltam kíváncsi.

Miért, a DRBD nem arra van tervezve hogy 2 node-os HA clustert építs vele?

A lehetetlenre hiába terveznek valamit, azt sose fogják tudni elérni... 2 objektummal sose fogsz megbízható HA clustert építeni. 2 objektumnak a quorumja ugyanis 2. Most vagy a quorumból engedsz, vagy nincs redundanciád.

Mert ha nincs quorum ellenőrzés, akkor sosem lehet biztos a cluster egyik fele, hogy a másik fele él vagy sem, ha nem bír vele kommunikálni. Ha ennek ellenére megy tovább, akkor megvan rá az esély, hogy a cluster másik fele is pont ugyanezt teszi, és a két cluster fél önálló életet kezd élni.
Ha van quorum ellenőrzés, akkor pedig redundanciád nincs, mert bármelyik cluster fél leállása a teljes cluster leállását eredményezi (mindkét node kell a quorumhoz).

Ezt mar annyiszor leirtatok.
O viszont arrol beszel, h csinal fencinget es a 'gyorsabb kutya baszik' alapon donti el a quorum helyett, h wtf.

Nehanyan erre irjak, h veszelyes, erre o meg azt irja, h vallalhato.

Mindenki leirta a gondolatat.
Tenyleg nem tudtok tullepni? Vagy en ertek felre vmit?:D

+1 arra, hogy használja mindenki azt ami szerinte a legjobb. Nálunk is van FC SAN a DRBD mellett, mert van ügyfél aki abban bízik.

Az viszont tény, hogy bőven vannak helytelen prekoncepciók a DRBD-vel kapcsolatban, nekem is voltak, de tanulni lehet abból, ha ezek ledőlnek - talán még akkor is, ha sose foglalkozol DRBD-vel.

mondom, en is hasznalom ramdiszk-replikaciora :)

az eredetileg linkelt qnap-os cuccnal siman jobb ket desktoppc-re epitett drbd is, amennyiben kulon storagekent vannak kezelve. (bar nem vagyok meggyozodve, hogy a LIO tud mindent, ami ehhez normalisan kell, leven hogy az egyik redhatos arc most tolja be a patcheket [okt vege] lkmlre)

ja, ertem mar a problemad. szerinted en azt mondtam, hogy a drbd szar, pedig ezt nem allitottam, sot, en is hasznalom (ramdiszkeket replikalok raadasul).

en azt allitottam, hogy 2 gepbol nem lehet megbizhato, automatikus failovert tudo clustert epiteni, mert amikor az egyik gep azt mondja, hogy szerinte az "A" adat a jo, a masik meg azt, hogy a "B" adat a jo, akkor nem lehet matematikailag eldonteni, hogy kinek van igaza. es ezen akarmennyi know-how es tapasztalat sem tud valtoztatni :)

a cephet illetoen teljesen egyetertunk, a ceph istenkiraly, ha nem az lenne, nem mi vinnenk a hatunkon a ceg ceph reszet...

"en azt allitottam, hogy 2 gepbol nem lehet megbizhato, automatikus failovert tudo clustert epiteni, mert amikor az egyik gep azt mondja, hogy szerinte az "A" adat a jo, a masik meg azt, hogy a "B" adat a jo, akkor nem lehet matematikailag eldonteni, hogy kinek van igaza. es ezen akarmennyi know-how es tapasztalat sem tud valtoztatni :)"

Ez viszonylag egyertelmu es ebben egyetertunk (es szerintem dap kollega is :) ).

Valojaban a kerdes nem ez, hanem, hogy meg lehet-e oldani 2 geppel (esetleg kisebb kiegeszitok hasznalataval mint IPMI, switchable PDU, soros port, etc.), hogy a fenti helyzet "kozel soha" ne tortenjen meg. Ha igen, akkor mondhatjuk, hogy lehet 2 gepbol automatikus failovert tudo clustert epiteni.

En speciel az igen-re szavazok.

Épp ezért kell elkerülni a split-brain -t, ezért van a STONITH. Ha a STONITH nem sikerül, akkor a node nem fog promote-álni, hanem lesz egy UpToDate és egy Outdated mirror ami soha nem fog ütközni. Ha a STONITH sikerül, akkor megint nincs split-brain.

A split-brain csak súlyos hibák sorozata után történhet meg, tipikusan az üzemeltető hibájából.

+1 feltetelezve, h a postolo tudja mit akar es elbirja a rendelkezesre allo keretbol kijovo HW a kiszolgalando SW-t.

Ill annyit modositanek rajta, hogy inkabb vagy

a, berelnek gepet (4 ora alatt cserelik HW hiba eseten)
b, vennek ket gepet, de automatikus failover nelkul

Igy nem HA lenne a rendszer, hanem olyan, ami relativ keveset all, de az adatok integritasa biztonsagban lenne (ami mindig fontosabb).

( ncc1701 | 2014. 12. 09., k – 14:25 )

A minden pontban benne van az, h az egészet egy másik földrészen meg is ismétled, hátha cunami/földrengés van.

( seferbt v | 2014. 12. 09., k – 14:51 )

Ingyenes ESXi-t nyugodtan el is felejteheted. Ahhoz, hogy legyen HA, kell egy vcenter és 2 storage sem árt. Ha 1 storage van, akkor folyamatosan panaszkodni fog a vmware, hogy a HA-hoz neki 2 storage kell. Vcenter-es verziókért pedig már fizetni kell. És elég sokat.
A 2db szerver + 1 storage is működőképes, csak az nem lesz magas rendelkezésre állású. Ha 1 storage van, és az elborul, akkor mi lesz?
Egy magas rendelkezésre állású rendszer nem jön ki 1M Ft-ból, kb. a vasakra sem elég. Hogy ne menjünk messzire, veszel csak 2 QNAP NAS-t (mondjuk TS-469 Pro-t), ami vmware certified. De akkor is csak egy NAS, nem egy "komoly" storage. (komoly alatt itt most értsünk egy HP MSA 1040 vagy 2040-et, ami nagyságrendileg több millió Ft-os tétel, de nem nagy durranás) Csak a NAS-nak darabja kb. 300+Áfa, és máris ugrott a keret 75%-a, és akkor diszket, szervert, szoftvert (vmware licensz) még nem is vettél.

Egy normális, az igényekhez igazított rendszert össze lehet rakni ennyiből, de akkor nem a vmware lesz a barátod.
Házi barkács megoldásokkal meg lehet csinálni. De az üzleti oldalnak kéne eldönteni, hogy melyik a fontosabb. a HA, ebben az esetben azt az 1M Ft-ot toldják még meg párral, vagy az 1M Ft? Utóbbi esetben kezdjenek el barátkozni a gondolattal, hogy nem lesz HA. És igen lesz olyan, hogy várni kell, míg visszaállítod a rendszert mentésből, ha valami megdöglik.

"The number of heartbeat datastores for host is 1, which is less than required: 2"

To disable the HA error message:
1. Log in to vCenter Server.
2. Right-click the cluster and click Edit Settings.
3. Click vSphere HA > Advanced Options.
4. Under Option, add an entry for das.ignoreInsufficientHbDatastore.
5. Under Value, type true.
6. Click Cluster Features.
7. De-select Turn on vSphere HA and click OK.
8. Wait for all the hosts in the cluster to deconfigure HA, then right-click the cluster and click Edit Settings.
9. Click Cluster Features.
10. Click Turn on vSphere HA.
11. Click OK.

There you go I fixed it for you ;)

( KaTT v | 2014. 12. 09., k – 14:54 )

Amit én csinálnék, ahogy mások is előttem:

2 szerver, külön storage nélkül

szerverekhez ECC RAM, legyen IPMI, redundáns táp, legalább RAID 1 MIRROR, de én RAID 6-ot preferálom 4 disk alapon (hozzá 1-1 tartalék kezdésnek), abból bármelyik 2 elhal sincs adatvesztésed.
De ha DRBD-t használsz, aktív/passzív üzemmódban, elég lehet a RAID 1 MIRROR (HP RAID eszközöknél RAID 1+0 van, ha írsz, felváltva ír, majd tükrözi, ami nem rossz 2 HDD-vel).

Ide még egy napi mentés, távolról vagy bárhogyan.

DRBD-re meg virtualizációt.

Elgondolkoznék a részben használt szervereken is. HDD új, akár proci is, a többit használtan...

Sakk-matt,
KaTT :)

Ugyan nem engem kérdeztél, de mi pl több ilyet is üzemeltetünk és nagyon megbízható setupnak bizonyult. Tervezett leállásnál live migration, így a hostokat simán lehet szervizelni és a VPS meg sem érzi.

Viszont a RAID6 szerintem nem jó kompromisszum - az írási teljesítményt megtizedeled vele. A tripla redundanciát biztosítja a DRBD, azaz üzemszerű működés esetén legalább 4 disznek kell tönkremenni az adatvesztéshez a RAID10-ben, ezen a szinten szerintem tök fölösleges a négyszeres redundancia.

Ahogy mások is mondták, sok múlik a részleteken - redundáns kommunkáció, monitoring, stb. Nem elég hozzá egy step-by-step guide, érteni is kell mi történik, mitől működik. Ez tekinthető hátránynak is.

( freeoli v | 2014. 12. 09., k – 15:26 )

HA hekkelni akarsz és ennyi a keret akkor.

FreeNAS node A és B, azonos felépítéssel, szonkronban tartható, nevezhető magas rendelkezésre állású tárolónak.

Host hypervisor A és B ... ebből van több szoftveres lehetőséged.

Switch A és B.

Nem tudom, hogy a hardverek hogy jönnek majd ki ilyen összegből, de talán deszktopból kihozható. Viszont ezen a rendszeren én nem csinálnék túl sok frissítést ezután.

( andrej_ v | 2014. 12. 09., k – 15:51 )

Két belépő szintű szerverrel nézd meg a Hyper-V Server 2012-t.

A VM, nem a teljes datastore, de mindenképpen latency-vel (30 sec a legkisebb).
A dolog rákfenéje, hogy nem tudod, hogy konzisztensek-e a benne levő adatok az utolsó replikálás időpontjában, emiatt pl. az SQL Server-t vagy az Exchange-t nem is támogatja Replica-ban a Microsoft, szerintem inkább statikus tartalmakra használható.
Szóval, messze van ez az igazi HA-tól.

( AiRLAC v | 2014. 12. 09., k – 15:57 )

Mindjá' jönnek az MS fiúk és meg lesz mondva neked hogy hyperv ;)

( legoninja | 2014. 12. 09., k – 17:42 )

Nagyon sok jó ötlet elhangzott, de lehet, hogy érdemes lenne kicsit többet infót adni a feladatról/rendszerekről amiknek ezen a rendszeren futnia kell. Annyit tudunk, hogy vegyesen lesznek gépek, de mi a feladatuk?

( agoston | 2014. 12. 09., k – 20:31 )

Mi csináltunk egy KVM + Ceph megoldást. 2 KVM host (entry level dell X3-as serverek darabja 150e) + hasznalt 5-6 eves dell szerverek a ceph-nek (3db darabja 25e + 50e a diszkek). Ez most elvisz olyan 6-7 linuxot (nem en raktam ossze a minden szolgaltatas egy VM rendszert, gondolom ennek alapjait az m$ sales-nel kell keresni, akik minden service-hez kulon vasat adtak el a windows licenszek miatt), es 2 windows (7-est)-t.

Annak en semmi ertelmet nem latom, hogy a hypervisorok 0.0-as load-al menjenek egesz nap, szoval eloszor merd fel milyen cpu/diszk/memoria terheles varhato, es milyen csucsok vannak, es ahhoz tervezd.

A Glusterfs-t en nem probaltam, de 2 ismerosom, aki mar probalta ova intett tole.
A Ceph-el pl. egesz kellemes volt a tapasztalat, amikor az egyik node-ja kihullott.

A KVM-eket pedig virt-manager-el es libvirt-el oldottuk meg, aki most karbantartja annak kellett valami parancssornal kommerszebb felulet, a virt-manager-t cygwin alatt el tudtuk inditani, most el van vele.

A kesz ESXi alol hozott virt gepek diszkjei 1 paranccsal konvertaltuk, nem mondom hogy gepenkent nem kell kicsit turkalni kezzel a VM xml-jeben, de csak megoldjak egyszer a ceph tamogatast.

( bognarattila | 2014. 12. 09., k – 22:14 )

Vegyél két szervert (nem kell a legjobbat, de ne is vacakot), VMware vSphere Essentials, hozzá Veeam Backup Essentials. Még ki is jöhetsz a pénzből és jó cuccod lesz, viszonylag egyszerűen és gyorsan.

A tárolód felejtsd el ennyiért, barkácsolni sem látom értelmét.

Essentials mire jó? Nincs HA, nincs VMotion.
Egy sima Essentials Plus kellene neki legalább (vMotion, High Availability,vSphere Replication), az meg listaáron ~900k meg + a support és akkor vasat még nem vett.

Sima ESXi-n vannak már próbálkozások HA-szerűre, de az ugye meg nem production ready na meg nincs support
http://www.no-x.org/?p=953

Hogy érted, hogy mekkora késleltetéssel, mihez képest? Amikor replikál, akkor kerül át, gondolom lokálisan GbE adott (lesz), azon viszonylag "sok" adat átmegy "rövid" idő alatt. Persze ha videó vágás üzemel, akkor más számok jönnek ki, mint "általános" esetben.

Miként definiálod a replikációt? :-) Lehet szinkron replikálni, lehet aszinkron is replikálni, de van félszinkron is (többről nem tudok, de attól még lehet).
Itt aszinkron replikáció van, megvalósítása VM pillanatkép alapú (pillanatkép létrehozása akár elcsendesítéssel, "másolás", pillanatkép törlése).

Egy aszinkron replikáció nem tud szinkron lenni, de ez fordítva is igaz, mi ezzel a probléma?

Milyen "HA" részét? Egy replikáció önmagában nem "HA", a replikáció annyit jelent, hogy az adatok másolja valamilyen módon.

Egy aszinkron replikáció "tetszőleges" gyakoriságú lehet: futhat akár folyamatosan (nem javaslom), óránként, 4 óránként, naponta, de akár csak havonta is. Helyzettől függ, hogy ki miatt választ. Sőt: egy aszinkron replikáció akár jobb is lehet, mint egy szinkron replikáció, hiszen szinkron esetén nem feltétlenül tudsz adatkonzisztenciát biztosítani (de ez megint helyzet és megoldás kérdése).

A javasolt megoldás ebben a környezetben a rendelkezésre álló információ és tapasztalatok alapján megfelelő lehet. Van környezet, ahol nem javaslom az ilyen jellegű megoldást, mert nem oda való.

"HA" megoldást kért az induló post, 1M Ft-os keretből. Ebbe a "valamilyen gyakorisággal másolok közel negyedmiskás szoftverrel" szerintem nem fér bele.
Itt, a hozzászólásokban is az volt a feltételezés, hogy a "billenés" során időben nem megyünk vissza. Egyébként meg minél több adatot kell egy replikációs művelet során átvinni, annál nagyobb a kockázata annak, hogy másolás közben dől el az az oldal, ahonnan a másolás megy (evés közben jön meg a postás...) - jó kérdés, hogy ilyenkor mi van az életben maradt oldallal?
Szinkron esetben is lehet konzisztens replikát csinálni, annyi az egész rákfenéje, hogy naaagy távolság esetén a latency-nek lesz egy, a fizikai terjedési időből adódó minimuma.

- nem látom, hogy hol kért "HA" megoldást, redundanciát kért (ha HA-t kér 1m-ért, akkor ki kell ábrándítani)
- nem olvastam el az összes hozzászólást, nem tudom, ki mit feltételezett és miért (a beküldőn kívül más feltételezése nem is igazán érdekel, mert az csak fikció)
- 1M összeg határ van, a javasolt megoldásommal ez akár teljesíthető is lehet
- a leírt környezethez is passzol a javaslatom
- nem tudok jobb, olcsóbb, megbízható megoldást

"Magas rendelkezésre állású" - így kezdődik a cím :-D Azt meg HA-nak szokás rövidíteni, vagy nem? Két szerver, sok diszk, 1M-s keret - ha levonom belőle a 230-at, akkor egy szerverre kevesebb,mint 400E Ft jut... Hol lehet ennyiért diszkekkel megpakolt szervert (dupla táp, ipmi) venni? ha nincs ilyen, akkor nem fér bele 23% szoftverköltség.
Van olcsóbb megoldás, szóba került a ceph, a drbd - érdemes végigolvasni a hozzászólásokat - célszerűen thread-enként.

Fordítás szinten magas rendelkezésre állású = HA: valóban, igazad van. Én angol alatt a HA-t arra értem, ami kvázi automatikus, magyarul magas rendelkezésre állásúnak azt tekinteném, aminél felkészítették az infrastruktúrát a gyors hibareagálásra.

De teljesen mindegy, ha HA-ként is értjük, nem gondolnám, hogy érdemes lenne kínlódni ilyen keretek között olyan megoldással, amit üzletileg semmi nem indokol. Mert anyagban olcsóbb ugyan valami ingyenes alapú, de munkában biztosan sokkal több, az üzemeltetésről és a helyettesíthetőségről nem is beszélve.

Célszerűbbnek látom 2 olcsóbb szervert venni jobb minőségű rendszerrel, mint drágább hardvert olyan "olcsóbb" rendszerrel, ami macerás beüzemelni és üzemeltetni. Hiszen pont azért van két szerver, hogy legyen tartalék.

Használtunk már DRBD-t, de többet nem kérek belőle egyelőre, a játék ideje elmúlt. Ez több éve volt, lehet, hogy azóta jobb, lehet, hogy mi voltunk a bénák, de ha így is volt, akkor jó esély van arra, hogy nehéz lesz megfelelő üzemeltetőt keresni. Másként: nem szeretném a téma indító képességeit kétségbe vonni, de ha neki nem sikerül valami miatt belátható időn belül beüzemelnie a rendszert (üzletvitelnek megfelelő stabilitásba), akkor biztosan munkába is fog kerülni a projekt. Ha nem talál senki megfelelőt (aki a maradék pénzért megcsinálja a konfigurációt), akkor ott van két drága hardver szoftver nélkül, de a pénz elfogyott.

Persze vannak szituációk, amikor van lehetőség játszani, ezekből az utóbbi időben sajnos kimaradtam. Ami nálunk felmerült igényként, azokat ilyen pénzes cuccokkal hatékonyan meg tudtuk oldani. Igen, tudom, hogy snassz és kevésbé lehet vele arcot növeszteni, de hát ez van, nem szeretek éjszakákat gép előtt tölteni (amit jó eséllyel senki nem fizet meg és jobbat is el tudok képzelni).

Ha te a sw-t adod el, akkor persze, hogy olcsó szerver drága sw elvet vallod, de itt a teljes keret 23%-át javasoltad erre költeni, ami semmiképp sem vállalható - pláne úgy, hogy a működési módból következően, ha jól értem, nem blokk, hanem komplett vm szinten történhet időnként másolás.

Attól, hogy a sw ingyenes, még nem lesz bonyolultabb/nehezebb/macerásabb üzemeltetni, illetve nem lesz kevésbé cserélhető, mint egy fizetős termék, amihez szintén kell telepítői/üzemeltetői szakértelem - és a cserélhetősége is ugyanúgy korlátozott, ráadásul idővel pénzbe kerül a frissítése is...

Mi is használtunk DRBD-t, kellően jól dokumentált, tesztelt felállásban, és köszöni szépen, jól működött; Ganeti-t én csak teszt környezetben matattam, de dokumentáció alapján dolgozva teljesen jól működött a guest-ek ide-oda pakolgatása, illetve host elpusztulás esetén a failover is. Nem űrtechnológia - viszont blokk szinten replikál, tehát a gyakorlatban az van a slave-en, mint a masteren. (Ha DB-szerverről van szó, akkor mag adatbáziskezelő szintjén kell megoldani az adatok replikálását, és kész)

Szoftvert és hardvert is adok el, ilyen szempontból teljesen mindegy, ebben a nagyságrendben pedig egyiken sem lehet keresni, tipikusan több a munka és probléma, mint a várható haszon. Szerintem majd a téma indító jobban el tudja dönteni, hogy számára mi vállalható költség és mi nem vállalható.

"Nem blokk, hanem komplett VM szinten": ezt nem értem, a VM is blokkokból áll, csak a különbség megy át.

Mindenki azt használ, amit akar. Én ebben a mini-infrastruktúrában túlzónak érzem a DRBD-t és az azzal járó kockázatot bevezetés és üzemeltetés szintjén is, de nyilván tévedhetek. Ha megfelelő lenne a DRBD a téma indítónak, akkor sem gondolnám, hogy az általam javasolt megoldás rossz lenne, legfeljebb Neked nem tetszik, bár a 23%-on kívül semmilyen kézzel fogható érvet nem mondtál. De ha már itt tartunk, akkor írhatnál egy várható bevezetési időt (a téma indítónak mennyit kell ezzel foglalkoznia, ha nincs semmilyen előismerete), vagy Te mennyiért állítanád be neki a DRBD-t teljesen frankóra tesztekkel, és mennyiért vállalnád a kapcsolódó hibaelhárítást, milyen SLA-val (beleszámolva azt, hogy ha összeborul a DRBD, akár a produktív környezetet is magával rántja, tehát erősen kritikus komponens a rendszerben, milyen RTO/RPO várható, jobb-e, mint Veeam esetén).

Meglepne, ha DRBD problémával hamarabb boldogulna bárki (akinek nincs vele tapasztalata), mint Veeam problémával, arról nem beszélve, hogy a Veeam probléma legfeljebb a replikát érinti, míg DRBD probléma a produktív gépet is érintheti.

"Pénzbe kerül a frissítése is": az ingyenes frissítése is pénzbe kerül, mert foglalkozni kell vele. Ezzel a megközelítéssel az összes szoftver cég már rég bezárhatott volna. De valahogy mégsem, köszönik szépen és élnek/virulnak, a sznobizmus mellett valószínűleg más érv is szól mellettük. Ezzel nem az ingyenes/nyílt forrású szoftvereket szeretném leszólni, mert mi is használunk bőven, de erre a feladatra úgy gondolom az ismereteim alapján, hogy az általam javasolt termékek jó megoldást nyújtanak ár/érték arányban.

(A DRBD-t mi is életre hívtuk, teszteket is simán vett, üzemelt is egy darabig, de hosszú távon merültek fel vele dolgok, amik azt vetítették előre, hogy kár vele kínlódni, mert ha adott probléma megoldódik, akkor 6 hónap múlva várhatóan jön egy másik.)

> Te mennyiért állítanád be neki a DRBD-t teljesen frankóra tesztekkel, és mennyiért vállalnád a kapcsolódó hibaelhárítást, milyen SLA-val [...]

Fullos DRBD setup tesztekkel 2 óra (Puppet manifestből :). Havi 99.99% SLA vállalható, amibe kb 1 failover esemény fér bele havonta ha a hideg cache nem probléma. Az üzemeltetés a vas karbantartásából és verziókövetésből áll (rutinfeladatok), magával a clusterrel és a DRBD-vel az égvilágon semmi tennivaló nincs a kezdeti setup után, a monitoring felügyelete elég.
A disaster recovery on-site és off-site LV snapshot-okra építhető legkönyebben egészen nagy adatmennyiségnél is, elég jó időket lehet garantálni vele, a szoftver stack rugalmassága itt már big win.

Mi ezzel szoktunk számolni. Ha a mérnökórában nézzük, akkor alacsony költség egy ilyen setup, effektív. A számlán szereplő összeg persze más kérdés..
A valódi költségeket mindenesetre csak az ügyfél tudja kiszámolni, külsős nem..

Ezt csak úgy érdekességnek írom, nem vitatkozok a mondanivalóddal.

> DRBD-t mi is életre hívtuk, teszteket is simán vett, üzemelt is egy darabig [...]
Sajnos az a "baj" a DRBD-vel, hogy akkor is működik, ha _semmilyen_ feltétel nem adott a biztonságos üzemeltetéshez. Csak egy eszköz, ami úgy muzsikál, ahogy játszanak rajta.

Ha "Latency" alatt a replikációs gyakoriságot érted, akkor nincsen korlát (beállíthatod folyamatosra is), de:
- ennél gyorsabb jó eséllyel nem lesz, mert pillanatkép készítése, másolás, törlés kb eltart ennyi ideig
- a pillanatkép egy gyenge pont: ha valami miatt beragad valamelyik és ilyen gyakran készül pillanatkép, az gyorsan problémához vezethet
- a pillanatkép készítése megakasztja a virtuális gép futását, például VSS elcsendesítéssel még jobban: ha aktívan használt a VM, akkor zavaró lehet, ha nincs aktívan használva, akkor mivel vélhetően kevés adat termelődik, nincs értelme túl gyakran futtatni

Megnéztem, lehet Neked lesz igazad, látszólag ez jó lehet, elfogadható nekem az hogy kézzel indítom el a VM-et egy másik gépen ha meghalna alatta a vas. Ez max. 1 óra kiesés, az itt bele fér.
Én azt nem szeretném, hogy HW hiba esetén rohangálni kelljen eszközökkel (ja és az nem 1 óra kiesés amíg megoldódik egy HW hiba).

Szóval köszönöm, ebbe az irányba is el kezdek nézelődni!

Némi óvatosan megírt és kitesztelt scripttel akár automatikusan is indíthatod, így az egy órát is néhány percre le tudod szorítani.
Viszont figyelj rá, hogy ilyenkor indítás előtt valahogyan garantálnod kell, hogy a régi vas nem tér vissza mert akkor split-brain.

Mondjuk ha ez az eszközkészlet elég, akkor szerintem kár VMWare-ért fizetni, XEN/KVM + DRBD is megoldja ugyanezt, ugyanígy.

Én biztosan nem szkriptelném. Jó eséllyel többször lenne ebből probléma, mint abból, hogy leáll a hardver és távolról kézzel be kell indítani.

Nyilván lehet Xen/KVM + DRDB-vel szívni, de nem vagyok benne biztos, hogy érdemes, bár az idejével nyilván mindenki maga gazdálkodik. Ha forintosítani kell az óradíjakat, akkor a vSphere Essentials + Veeam alapú megoldás a végén olcsóbb is lehet (reális órabért feltételezve), ráadásul ezzel a kombóval normális mentés is megoldható kvázi néhány kattintással, szükség esetén könnyű visszaállítással (akár VM, akár fájl szinten).

Arról nem beszélve, hogy könnyebben találni helyettesítést VMware+Veeam esetén (megtanulni is könnyebb), mint Xen/KVM + DRDB-re.

VM fut egyik vason, a Veeam biztosítja a replikációt. Azt kell megoldanod, hogy távolról hozzáférj a rendszerhez: ha az elsődleges szerver megáll, akkor távolról elindítod a másik szerveren a replikát. Nem kell eszközökkel rohangálnod ahhoz, hogy újra működjön a szolgáltatás.

A replikáció gyakoriságától függően lesz adatkiesés (nem feltétlenül vesztés, mert később visszanyerheted - alkalmazásfüggő, hogy mit tudsz vele kezdeni), de 1m forint kb erre elég. Lássuk be: nem minden nap fordulnak elő hibák, így simán elegendő lehet ez a megoldás.

Gyakorlatilag erről van szó, igen.
Általad meghatározott időközönként:
- pillanatkép létrehozása a VM-ről (akár elcsendesítéssel)
- változások átmásolása egy tükör virtuális gépbe
- pillanatkép törlése

A pillanatkép vonatkozást át kell gondolni, de kis esélyét látom annak, hogy ez ebben az infrastruktúrában gondot okozna.

elod részben megválaszolta:
- én ezt ismerem, használom, bevált
- ESXi vs Hyper-V: mindenki döntse el maga, melyiket szeretné és miért
- a Veeam tud biztonsági mentést is, amire a replikáció mellett jó eséllyel szükség van
- Veeam Backup and Replication működik Hyper-V-vel is (sőt: "changed block tracking" megvalósítás is készült hozzá, mivel az MS még nem volt képes összehozni)

( _Franko_ v | 2014. 12. 10., sze – 16:09 )

Mennyi a pénzben realizált veszteség és/vagy elmaradt bevétel, ha áll valamelyik szolgáltatás?

+1

A "nagyon kevés pénzből 100% rendelkezésre állás" ötletek a legtöbbször ott születnek, ahol egyébként 5000 Ft kiesést sem okoz, ha egy napig nem működik a szolgáltatás. Egyáltalán nem számolnak utána, hogy megtérül-e valaha a fejlesztés.

Ráadásul azt hiszem senki sem írta, hogy ha a kérdező nem maga állítja össze az egész rendszer az elejétől a végéig, akkor az 1 milliós keret jelentős részét elviszi maga a munkadíj...

Még akkor is érdemes átgondolni, ha van sok pénz... sőt, általában azért van sok pénz, mert arra költik, amire kell és arra nem költik, ami az üzletmenet szempontjából felesleges.

Persze létezik az a szakmai hiúság, amikor a lehető legjobbat szeretné megcsinálni az ember, mind IT, mind üzleti oldalról, csak közben egy szimpla kockázatelemzés és költségterv sem készül vagy tele van olyan számokkal, amelyekről messziről látszik, hogy "valami nagyot írjunk oda" alapon készültek. :)

Ebben az esetben simán kijöhet, hogy az egy millió forintos költségvetés is túl nagy, akár az is, hogy a tízmillió is vállalható a kiesés okozta veszteségekhez képest. A 'van x pénz, csináljunk valamit' jellegű munka arról árulkodik, hogy nincs átgondolva se a feladat, se a megvalósítás, se a cél.

Nyomtassatok ki egy ilyen képet A3 méretben, üljetek össze egy órára és mindenki írjon mindegyik helyre valamit, aztán amikor mindenki egyetért, nézzétek meg, hogy mi lett a vége:
http://media.agile42.com/content/lean-canvas.png

...általában teljesen más lesz, mint amire gondoltál előtte... mert esetleg teljesen más a gyökér oka a problémának, mint amit kezdetben sejteni lehetett.

( uid_4656 v | 2014. 12. 10., sze – 21:30 )

Ennyi pénzből "gyári" (gyártói támogatással ellátott) módon nem tudsz HA rendszert építeni.

Barkácsmódszerekkel össze lehet rakni többféleképpen is (pl. KVM + drbd), de az összerakón kívül senki más nem fogja tudni üzemeltetni a rendszert, így az összerakó az összerakás után hülye lenne nem nagyon sok pénzt kérni az üzemeltetésért. :-D

van még egy olyan is, h Xen Kemari
emlékeim szerint v a Remus v a Kemari csinálja azt, hogy nemcsak a háttértárat sync-eli, hanem a memóriát is (mintha live migrate lenne, csak nem zárja le a sync-et).

Volt róla valami videó is, hogy kliens gépről videót néztek a domU-ról. Egyszer csak kihúzták a delejt a primer dom0-ból, és a videó kb minimális reccenéssel ment tovább.

Na ilyet nem szeretnék csinálni! Szép rendszert próbálok a lehetőségekből kihozni, ha nem lehet akkor vagy az ár megy feljebb vagy az igények mennek lejjebb! Nem így akarok pótolhatatlan lenni.

Olvasom a hozzászólásokat és próbálok tanulni/ötletet meríteni belőle, hogy mások hogyan csinálnák/csinálják.

Ezért egyébként mindenkinek köszönet, aki eddig írt!

( hzsolt94 v | 2014. 12. 10., sze – 22:09 )

Hasonlóan alacsony keretből storage nélkül üzemeltetünk gépeket. 2-esével vannak párban DRBD-vel replikálva a diszkek, felette XEN-en futó virtuális gépen a szoftver. Ez így nem valódi HA/Cluster, de bármikor 1 kattintással átállhatsz tartalékra (=> nagyon kicsi downtime) illetve ha tervezett karbantartás kell, akkor live migrációval is átviheted a gépeket (=> 0 downtime) és bármelyik gépet karban tudod tartani, újraindítani.

Nálunk még egy harmadik pici szkript is van egy külső (nem redundáns) gépen, ami ssh-val automatikusan átlövi a tartalék gépet online-ba szükség esetén + biztos ami biztos alapon lekapcsolja az eredeti gépnek a portjait a switchről (így ha futott is offline, nem térhet vissza a "régebbi" adatokkal működésbe, nem lesz valódi split brain az üzleti adatok tekintetében)

Ezzel így sokkal nagyobb uptime-ot tudsz elérni mint egy hardverrel, és nagyjából vállalhatóak a költségei is.

( AiRLAC v | 2014. 12. 10., sze – 23:49 )

"Magas rendelkezésre állású szerver infrastruktúra"
vs
"Ez max. 1 óra kiesés, az itt bele fér."

dafuq? :)

( seferbt v | 2014. 12. 11., cs – 18:22 )

ha 1 storage-ra tesz több datastore-t akkor se lesz kisegítve, ha a storage elborul. Akkor az azon hiába van n+1 datastore, ugyanúgy nem fog menni semmi.

Nincs nálad valami kicsit összekeveredve?

1 storage (már amit tényleg storage-nek hívunk) általában 2 head, 2 switch (fc/ethernet), két betáp, két tűzoltórendszer, két klíma, két lokáció.

A két datastore egy gyári érték, eltérhetsz tőle, DE ebből nem az következik hogy KÉT storage rendszered kell legyen. Ez ilyen akváriumos logika, már bocs.

Az 1 storage ilyen keretek között számomra 1db NAS-t vagy más egyéb eszközt jelent, ami mondjuk max. valami RAID szintet tud, nincs dupla betápja, 2 kontrollere, 2 FC switch, stb. Itt egy EVA, 3par, vagy hasonló, georedundánsan nemigen férne bele a keretbe.
Szóval az itteni storage most nem az a storage, mint amire normál esetben gondol az ember HA hallatán. De akkor a storage szót a kommentjeimben cserél ki mondjuk NAS-ra. Úgy jó lesz? :)