Windows 2012, Hyper-V, stoarge intern si HA sau asa ceva

[hulubei]

Uite cum îmi storc mintea câte 30 minute zilnic de vreo săptămână.
Un prieten are două servere cu Windows 2012 Hyper-V pe ele ce rulează ceva mașini acolo (inclusiv DC-uri, un Exchange, etc.). Dorește să mute un server într-o altă locație pe motive de siguranță (locația actuală a pățit diverse inundări sau căderi de tensiune pentru ore întregi). Stoageul este format din HDD SAS interne în RAID (servere Dell, controller Perc).
Neexperimentat fiind în Hyper-V dar văzând marketing, am zis că îi dăm de cap să facem o soluție HA like pentru problema lui. Poate nu chestii live, o simplă replicare ca cineva să apese start la mașiniile din partea cealaltă de recovery. Am zis că e simplu dar se pare că nu este.
Am mers în primă etapă pe StarWind iSCSI. Am montat pe fiecare server targetul local (greșesc aici?). Validarea de Cluster în Windows îmi zice doar că nu am drive de Quorum. Tutorialele mă învață să-l creez doar ca nu reușesc să atașez niciun drive la storage-ul clusterului. După încercări multiple am zis să trec la soluția integrata de File Server chiar a Windows-ului dar nici aici nu pot adăgua niciun drive, de parcă nu am storage deloc. Evident, Microsoft mă depășește. Îmi dați idei, cum pot face sa utilizez aceste două servere în așa fel încât să-și sincronizeze cumva storageul între ele?

 

[AdrianB1]

Vrei o solutie mai robusta pentru diverse aplicatii (pentru DC e banal) sau vrei sa replici 2 servere la distanta?

Daca vrei o solutie robusta pentru DC faci cate un server virtual in fiecare locatie si se sincronizeaza singure; daca vrei pentru Exchange nu am idee, nu m-am gandit la asta pana acum.

Daca vrei replicarea serverelor din locatia A in locatia B le lasi oprite pe cele din locatia B si faci sincronizare de pe A pe B la storage.

Nu mi-e clar daca discutam despre acelasi lucru.

 

[hulubei]

DC-ul este clar. Doar că mai sunt ceva VM-uri pe acolo, pe lângă Exchange, al căror mediu de clustering este inxistent (câtvea app server ce nu au fost concepute în acest fel și nici nu vreau să inventez eu soluțiile care să pseudoclusterizeze soluția).
Evident, prima gândire a fost să replic storageul iar în zona de DR să țin mașinile oprite (cică). Din păcate nu înțeleg unde greșesc sau cum să fac replicarea cât mai bine. StarWind teoretic trebuia să facă asta dar nu vedeam drive-urile iSCSI în managerul de cluster al lui Windows 2012. Ulterior am încercat doar să copiez ceva arhive (500-800MB) și deși vedeam instant activitate pe rețea, semn că replicarea avea loc, în zona cealalta nu vedeam nimic nici dupa zeci de minute. Deci soluția nu mi se pare stabilă ori nu știu eu să o fac.
Astfel, soluții de replicare storage local al serverului, aveți în minte? Sau recomandați vreo soluție de replicare de VM-uri (la VMWare știam vreo două soluții care făceau asta, pe Hyper-V niciuna).

 

[miahi]

N-am folosit, dar Replica pare să fie ce vrei - replicare la nivel de VM aproximativ on the fly (scheduled la intervale scurte, după cum arată trimite delta de snapshots de fapt).

 

[hulubei]

Mulțumesc, miahi ! Nu știu de ce am ignorat această opțiune și căutam avioane oribile sau ulterior la soluții dedicate de replicare.

 

[miahi]

Funcționează? Am folosit Hyper-V doar ca end-user, pot doar să asociez cu conceptele din ESXi. Presupun că dacă reușeai trick-ul cu cluster-ul cu shared storage puteai să faci și migrare on the fly (cam așa e la ESX, dacă ai setat fierul în cluster și ai aceleași resurse pe ambele mașini le poți muta între ele când îți place).

 

[hulubei]

Nu am făcut încă testele de Fail Over automatizate dar mă bucură că își face la 5 minute update la replică. Loadul nu va fi mare sper eu și sper să nu am vreo problemă cu lățimea de bandă când serverele vor fi conectate între ele printr-un VPN de vreo 5-6Mbps.
Live Migration și alte șmecherii ar fi fost frumoase dar în general se pretează în clustere pentru LB sau HA și mai puțin în cazul meu unde mai mult aplic ideea unui DR.

 

[miahi]

Eu sper să testez cât de curând un application DR de genul ăsta, dar just for fun, pentru că am mers pe ideea cloudy de dumb workers fără cine știe ce în stocarea locală, un temp storage shared și în rest totul în DB, pentru care există tone de soluții de DR, care mai de care mai scumpe (Oracle).