High Availability (HA) reprezintă un concept managerial dincolo de moda tehnologică. Este o necesitate de care depinde succesul unei afaceri. Parte componentă a triadei manageriale CIA, disponibilitatea (availability în engleză) reprezintă componenta cea mai costisitoare din arhitectura unui sistem informaţional, datorită investiţiilor în dispozitive hardware redundante sau care să suporte clustering-ul.
Un alt concept vehiculat în arhitecturile de disponibilitatea maximă este single point of failure, care presupune crearea unei infrastructuri redundante, în aşa încât un serviciu informaţional să fie disponibil cât mai mult timp clienţilor săi.
Cheia succesului unei soluţii de HA este aceea a gradului de disponibilitate oferit serviciilor, preţul implementării şi nu în ultimul rând timpul de recuperare în caz de dezastru, pentru că oricât de sigură ar fi o soluţie, într-o zi tot se poate întâmpla ca toată infrastructura să fie indisponibilă.
Modelul general de arhitectură HA (fig.1).
După cum observați în imaginea de mai sus arhitectura HA este pe mai multe niveluri combinând niveluri logice cu niveluri fizice.
În continuare voi prezenta pe scurt câteva explicații, nivel cu nivel de jos în sus. Cheia centrală a modelului este aceea a utilizatorului care are nevoie permanent de acces la serviciul de Web. Toată arhitectura este transparentă față de acesta.
A. DataStorage
Din ce în ce mai multe companii folosesc sisteme de stocare centralizată, care au foarte multe avantaje. Esențial în schimb în alegerea unui datastorage este funcțiile de iSCSI pe care din păcate nu le oferă toate sistemele. Altele oferă funcții de iSCSI la nivel de conexiuni de cabluri, destul de greu de înțeles… din punctul meu de vedere.
În cazul în care nu avem posibilitatea să creem partiții și funcții de iSCSI din aplicația de administrarea a storage-ului, atunci putem crea partiții simple de tip RAID 5, pe care să le alocăm serverelor din nivelurile fizice ulterioare.
În imaginile de mai sus puteți vedea un model de identificare a host-urilor iar în imaginea 2 modul în care este mapat spațiul de stocare pe un host. Corelat cu arhitectura din fig.1 în modelul nostru serverul iSCSI Target Server este identificat sub numele v-iSCSI-Master.
Cum funcționează HA în acest caz? În momentul în care cade din punct de vedere fizic un disc din datastorage, partiția logică RAID 5 rămâne activă și funcțională. Trebuie doar să înlocuim discul căzut într-un termen relativ scurt.
B. iSCSI Target Server
Dacă ne uităm cu atenție pe arhitectura din fig.1 observăm că acesta este singurul ”Single Point of Failure”. Pentru a rezolva această problemă putem adăuga un alt server iar stocarea hardiscurilor virtuale (VHD-urilor) se poate configura într-un DFS (Distributed File System).
În modelul pe care îl propun aici, iSCSI serverul este un Windows Server 2008 R2. În mod nativ, sistemul iSCSI este compus din două părți: target-ul și initiator-ul. Dacă datastorage-ul nu are nativ funcția de iSCSI Target, atunci pot fi folosite diferite aplicații în acest sens pentru a emula un astfel de rol.
Pentru a transforma un server Windows într-un iSCSI Target trebuie să parcurgeți următoarele etape:
1. Instalarea componentelor pentru Windows Storage Server. Ediția Windows Storage Server 2008 R2 Embedded (Standard, Enterprise, Workgroup) with iSCSI Software Target 3.3 (x64) poate fi descărcată de abonații MSDN începând cu 27/09/2010.
Atenție WSS nu este un sistem de operare în sine ci o colecție de update-uri care se instalează din Windows_Storage_Server_2008_R2.iso.
2. Instalarea iSCSI Software Target 3.3 folosind aceeasi sursă de pe MSDN.
După instalare se pornește automat serviciul WinTarget și trebuiesc definite discurile virtuale și apoi serverele care vor folosi aceste discuri.
Puteși găsi aici două articole foarte faine de configurare iSCSI și pentru în mod detaliat iSCSI pentru Hyper-V.
iSCSI Target Server – Config summary (fig.2)
Fiecare server care va accesa discurile virtuale create la Devices va trebui definit în secțiunea iSCSI Targets. Definirea lor se face pe baza IQN (iSCSI Qualified Name) care reprezintă un mod de identificare a clienților de iSCSI în rețea. Fiecare nume ale clienților windows de iSCSI va fi format după algoritmul: iqn.1991-05.com.microsoft: urmat de numele de DNS al acestuia.
Exemplu de IQN Windows: iqn.1991-05.com.microsoft:srv-cluster-n1.feaa.uaic.ro
C. Configurarea Clusterului de Hyper-V
Dacă vorbim de un cluster este clar că putem implica mai multe servere simultan. Din lipsă de echipamente eu am configurat doar două servere care să partajeze rolul de Hyper-V.
Pașii în configurarea inițială a unui nod din cluster
1. Instalarea sistemului de operare: Am ales Windows Server 2008 R2 Datacenter pentru a putea stoca mai mult de 4 servere virtuale folosind aceeași licență.
2. Instalarea rolului de Hyper-V R2. Componenta de Live Migration nu este disponibilă decât în idițiile R2.
3. Instalarea feature-urilor de Multipath I/O și Failover Clustering
Multipath I/O este componenta care permite accesul la același disc a mai multor servere, iar Failover Clustering pentru a putea partaja același serviciu, în cazul nostru Hyper-V.
4. Configurarea iSCSI Initiator pentru conectarea la iSCSI target.
Se scrie la Target numele IQN al target serverului definit mai sus și se apasă Quick Connect.
5. Configurarea Volumelor
După inițializarea lor în Volumes and Devices trebuie să mergem în Disk Manager și creem partiții simple fără literă, dar care trebuie să fie on-line. În imagine ele sunt off-line pentru că așa au fost configurate de Cluster.
6. Operațiunile 1-5 se execută și pe nodul al doilea.
7. Se validează cluster-ul din Failover Cluster Manager
Dacă testul a fost parcurs cu succes se poate trece la configurarea clusterului.
8. Configurarea clusterului
Cerințele minime pentru un nod: două plăci de rețea conectate în două rețele diferite și toate nodurile să aibă conectate la iSCSI target.
De asemenea, este esențială configurarea în DNS a unei înregistrări de tip HOST care va fi alocată cluster-ului.
9. Crearea unei mașini virtuale.
O mașină virtuală se poate crea direct din consola de administrare a clusterului de la Services and Applications, Virtual Machines, New Virtual Machine și se alege nodul din cluster pe care dorim să realizăm instalarea.
10. Testarea Live Migration (HA)
Live Migration în cluster înseamnă că la orice cădere a unui nod, sau oprirea acestuia pentru operațiuni de întreținere, este oarecum transparentă față de utilizatori.
În momentul în care un nod nu mai este disponibil mașina virtuală devine în scurt timp disponibilă de pe nodul al doilea.
Haideți să vedem un scurt filmuleț pe această temă.
În configurarea din filmuleț, mașina virtuală se numește Test (Windows 7, 512 MB RAM) și are IP (10.10.1.216) alocat dinamic din DHPC. Eu mă uit la un film de pe YouTube în mașina virtuală, conectat prin VPN L2TP.
Nodul 1 din clustrer (srv-Cluster-N1) este Owner-ul curent și are IP intern 10.10.3.211. Voi face restart la acest nod iar după câteva secunde voi revedea filmul de pe nodul 2 (srv-Cluster-N2, 10.10.3.212) care devine noul owner al mașinii virtuale. Odată cu migrarea live se realizează și migrarea paginilor de memorie.
Reiau povestea:
1. Incep să ma uit din remote la film
2. De pe nodul 2 verific faptul că masina virtuala este pe Hyper-V din Nodul 1
2.1. Încep un ping –t către mașina virtuală
3. De pe nodul 1 verific faptul că Owner este nodul 1
4. Dau restart la nodul 1
5. Vedem ce se întâmplă la ping și la vizualizarea filmului.
Câteva secunde pentru mutarea paginilor de memorie de pe un server pe altul și încă 5-10 pentru refacerea conexiunii prin remote desktop.
Un studiu de caz românesc pe tema Hyper-V puteți găsi la adresa: http://www.clubitc.ro/?p=11601 în care High Availability pentru serverele Linux este asigurată prin Hyper-V. Dacă aveți și alte cazuri de succes de pe la noi vă rog să lăsați un comentariu.
Mulțumesc.
Sper că v-a plăcut și că vi se pare util. Nu uitați! Disponibilitatea este o cerință de business nu un moft tehnic.
Succes!
Valy Greavu - Live Blog 