Przedstawiamy, w jaki sposób zbudować ekonomiczną pamięć masową typu fiber channel SAN storage pracującą pod kontrolą systemu operacyjnego Linux Openfiler ESA i współpracującą z klastrem wysokiej dostępności VMware ESXi w zakresie podstawowej zdolności przyłączeniowej, odporności na uszkodzenia oraz pełnej redundancji połączeń światłowodowych pomiędzy pamięcią masową a klastrem HA.

W artykule przedstawiono klaster wysokiej dostępności z pełną redundancją połączeń światłowodowych jako platformę dla maszyn wirtualnych współpracujących z systemem pamięci masowej typu fiber channel SAN storage. W budowie klastra wykorzystano technologię wirtualizacji firmy VMware, wspierającą wiele różnych systemów pamięci masowych typu Storage Area Network (SAN). Produkowane obecnie przez VMware oprogramowanie VMware ESX Server klasy enterprise przeznaczone dla organizacji i podmiotów gospodarczych różnej wielkości służy do tworzenia wirtualnej infrastruktury informatycznej. Opiera się na własnym kernelu oraz konsoli zarządzającej, którą jest zmodyfikowany system operacyjny Red Hat Linux, posiadający własne sterowniki i obsługujący specyficzny sprzęt komputerowy. Openfiler ESA jest natomiast systemem operacyjnym, który zapewnia obsługę zarówno plikowych (typu NAS – Network-Attached Storage), jak i blokowych pamięci masowych (typu SAN storage).

Ogólną koncepcję budowy wspomnianego klastra przedstawiono na rys. 1. Zasadniczą rolę pełni tutaj sieć światłowodowa Storage Area Network (SAN) z przyłączoną do niej pamięcią masową, pracującą pod kontrolą systemu operacyjnego Linux Openfiler ESA w wersji 2.99.1.

> Instalacja i konfiguracja klastra HA

W związku z potrzebą budowy ekonomicznego klastra laboratoryjnego w zakresie podstawowej zdolności przyłączeniowej, odporności na uszkodzenia FT oraz pełnej redundancji połączeń światłowodowych pomiędzy klastrem a pamięcią masową typu fiber channel SAN Storage pracującą pod kontrolą systemu operacyjnego Linux Openfiler ESA, zainstalowano go i skonfigurowano na dwóch maszynach IBM System X3500 z oprogramowaniem serwerowym VMware ESXi 5.5. Klastrem zarządza się za pomocą pakietu oprogramowania VMware vCenter Operations Management Suite 5.8, tj. VMware
vCenter Server Appliance ver. 5.5, które zostało zainstalowane na oddzielnym 64-bitowym serwerze zarządzającym z oprogramowaniem serwerowym VMware ESXi ver. 5.5.

Oprogramowanie administracyjne w postaci pakietu VMware vSphere Client 5.5 zarządzające klastrem zainstalowano na kolejnym 64-bitowym komputerze. W celu instalacji oprogramowania VMware vCenter Server Appliance skorzystano z kreatora tego oprogramowania z poziomu klienckiego programu zarządzającego vSphere Client, które wcześniej zainstalowano z pliku VMware-vCenter-Server-Appliance-5.5.0.10000-1624811_OVF10.ovf. W celu uzyskania dostępu do konsoli administracyjnej VMware vCenter Server Appliance na serwerze zarządzającym uruchomiono maszynę wirtualną o nazwie VMware vCenter Server Appliance (rys. 2). Dostęp do uruchomionej konsoli maszyny wirtualnej VMware vCenter Ser­ver Appliance możliwy jest za pomocą dowolnej przeglądarki internetowej, wykorzystującej wyświetlany adres IP.

Właściwą strukturę klastra utworzono za pomocą kreatora z pakietu VMware vSphere Client for ESXi servers, zainstalowanego na konsoli administracyjnej. Podczas pracy kreatora klastra skonfigurowano następujące opcje oraz funkcje:

• włączono opcję wysokiej dostępności – Turn On vSphere HA;
• włączono opcję monitorowania hostów – Enable Host Monitoring;
• ustalono wysoki priorytet restartu klastra oraz maszyn wirtualnych – VM restart priority – High;
• wyłączono opcję statusu monitorowania maszyn wirtualnych – VM Monitoring Status – Disabled;
• wyłączono opcję wzmocnionej kompatybilności – Enhanced vMotion Compatibility – Disable EVC;
• ustalono lokalizację plików typu swapfile – Store the swapfile in the same directory as the virtual machine.

W celu zapewnienia możliwości przenoszenia wirtualnych maszyn pomiędzy hostami i klastrami (VMotion) oraz odporności na awarie (Fault Tolerance, FT) utworzono wewnętrzną sieć komunikacyjną o nazwie VMotion and Fault Tolerance. Dla pierwszego hosta ESXi (192.168.0.71) ustalono wewnętrzny adres IP 50.50.50.1 (maska 255.255.255.252) oraz odpowiednie opcje wyboru (rys. 3). Podobnie dla drugiego hosta ESXi (192.168.0.71) ustalono wewnętrzny adres IP 50.50.50.2 (maska 255.255.255.252) oraz odpowiednie opcje wyboru.

[...]

Autor pracuje jako specjalista ds. wdrożeń, zajmuje się implementacją nowych technologii w infrastrukturze serwerowej. Jest doktorantem, twórcą artykułów naukowych i technicznych publikowanych w czasopismach.