Strona korzysta z plików cookies w celu realizacji usług i zgodnie z Polityką Plików Cookies.



11.12.2017

Dla biznesu

BenQ MH760
07.12.2017

Pamięć masowa SDS

SUSE Enterprise Storage 5
05.12.2017

Bezpieczna platforma

Red Hat OpenStack Platform 12
30.11.2017

ITewolucja w bezpieczeństwie....

9 listopada w katowickim hotelu Novotel odbyła się kolejna odsłona konferencji z cyklu...
28.11.2017

Smukle i elegancko

HP Spectre 13 i x360
23.11.2017

Z IEEE 802.3bz

Przełączniki Netgear
21.11.2017

4K z USB-C

EIZO FlexScan EV2785
16.11.2017

Wielofunkcyjne MFP

Canon imageRUNNER ADVANCE C256i, C356i oraz C356P
14.11.2017

Fabryka Przyszłości w drodze...

W dniach 25 i 26 października we Wrocławiu odbyła się czwarta edycja konferencji...

Testujemy vmware vSAN i VxRail

Data publikacji: 09-05-2017 Autor: Marek Sokół

Po wstępie teoretycznym z poprzedniej części przyjrzymy się maszynie VxRail z vSAN na pokładzie. Przejdziemy przez proces instalacji klastra, sprawdzimy, jak rozwiązanie reaguje na awarie komponentów, by na końcu obserwować pracę pod obciążeniem.

Hiperkonwergencja w wydaniu VMware jest produktem bardzo ciekawym. Mając przygotowany sprzęt, bardzo łatwo jest uruchomić klaster vSAN, samo skompletowanie urządzeń może jednak być kłopotliwe i czasochłonne – nie wszyscy klienci są gotowi samodzielnie podjąć się takiej pracy. Bardzo dobrym wówczas wyjściem jest wykorzystanie gotowego rozwiązania, jakim jest VxRail – dedykowanego sprzętu skonfigurowanego zgodnie z potrzebami klienta. Przyjrzyjmy się zatem uruchomieniu hybrydowego klastra VxRAIL.

Testowany model to VxRAIL 120 wersji 3.5 (vsphere 6.0 update 2), bazujący na czterech serwerach firmy Quanta zamkniętych w jednej obudowie wysokości 2 RU. W skład pojedynczego serwera wchodzą:
 

  • dwa procesory Intel Xenon E5-2620 v3 2,4 GHz,
  • 192 GB RAM,
  • jeden dysk SSD 400 GB,
  • cztery dyski HDD 1,2 TB,
  • dwa porty sieciowe 10 GbE,
  • jeden port IPMI do zarządzania serwerem,
  • port VGA,
  • dwa porty USB.


Dodatkowo w ramach wspólnej obudowy znajdują się dwa zasilacze. Dostęp do interfejsów serwerów jest realizowany od tyłu, od przodu natomiast obudowa w całości jest wypełniona dyskami. W takiej architekturze poszczególne serwery z obudowy wyjmuje się od tyłu, co może być kłopotliwe zarówno ze względu na istniejące okablowanie, jak i wymagane miejsce potrzebne na pełne wysunięcie serwera.

Warto zauważyć, że obudowa testowanego systemu pozwala na wykorzystanie sześciu dysków na serwer, natomiast zainstalowane są tylko cztery. W razie konieczności zwiększenia rozmiaru przestrzeni dyskowej w klastrze wystarczy zamontować kolejne dyski. Gdyby taka operacja była niewystarczająca lub spadek stosunku pojemności dysków SSD do HDD (zalecany przez producenta to 1/10) był nieakceptowalny, wówczas dodajemy do klastra kolejne serwery. Oczywiście można byłoby dodać kolejne dyski HDD, a dyski SSD wymienić na większe, aby utrzymać właściwą proporcję, jednak takie działania prowadzą do rezygnacji z korzyści stosowania modelu VxRail i rozpoczęcia samodzielnego projektowania sprzętu, czego staraliśmy się od początku unikać, pozostawiając projektowanie sprzętu w rękach dostawcy.

Po montażu i okablowaniu sprzętu możemy przejść do konfiguracji klastra. Wirtualna maszyna VxRAIL manager domyślnie uruchamia się z adresem statycznym 192.168.10.100, a hosty ESXi oraz interfejsy zarządzania konfigurowane są z serwera DHCP. Należy zatem odpowiednio przygotować serwer DHCP (najwygodniej, aby przydzielał on adresy z podsieci 192.168.10.0/24). Warto także wspomnieć, że hosty ESXi w domyślnej konfiguracji dostępne są na nietagowanym VLAN-ie (management). Na przełącznikach sieciowych, do których podłączone są węzły klastra, warto przygotować dwa VLAN-y do celów ruchu klastra vSAN oraz ruchu vMotion.

Po zakończonej konfiguracji sieciowej i włączeniu wszystkich węzłów należy podłączyć komputer administratora do VLAN-u zarządzającego hostów ESXi. Komputer ten powinien być także skonfigurowany z przygotowanego wcześniej serwera DHCP.

W kolejnym kroku uruchamiamy przeglądarkę i możemy rozpocząć konfigurację klastra (patrz ramka).

W trakcie procesu instalacji mamy możliwość uruchomienia vRealiza Log Insight, które jest częścią rozwiązania VxRail, szkoda jednak, że dostawca nie dał możliwości uruchomienia monitorowania środowiska w postaci vRealize
Operations. Oczywiście jest możliwe włączenie wspomnianego rozwiązania już po uruchomieniu całego środowiska, wymaga to jednak dodatkowego czasu, którego producent nie chciał nam zaoszczędzić.

Proces instalacji jest maksymalnie uproszczony i nie nastręcza większych problemów. Pewną niedogodnością jest konieczność posiadania serwera DHCP, jednak jego uruchomienie pozwala zaoszczędzić wiele czasu, który trzeba byłoby poświęcić na ręczną konfigurację każdego hosta. Z drugiej strony trudno sobie wyobrazić produkcyjne środowisko bez serwerów DNS. Ciekawa jest natomiast możliwość uniezależnienia się od serwera DNS, co w małych lub testowych środowiskach jest bardzo wygodne i oszczędza część prac konfiguracyjnych. W sytuacji gdy zdecydujemy się uruchomić dodatkowe centrum przetwarzania danych z osobną instancją serwera vCenter, brak dedykowanych serwerów DNS zacznie już bardzo doskwierać. Czas wdrożenia nowego klastra został skrócony do minimum, praktycznie wyeliminowano wszelkie błędy, które można by popełnić podczas konfiguracji środowiska ręcznie – pozwala to szybko i sprawnie oddać do użytku nowe zasoby obliczeniowe oraz przestrzeń na dane. Późniejsza rozbudowa też nie powinna nastręczyć problemów.

 

[...]

 

Autor jest administratorem systemów IT. Zajmuje się infrastrukturą sieciowo-serwerową, pamięciami masowymi oraz wirtualizacją. Posiada tytuły VCP, MCP oraz CCNA.

Pełna treść artykułu jest dostępna w papierowym wydaniu pisma.

.

Transmisje online zapewnia: StreamOnline

All rights reserved © 2013 Presscom / Miesięcznik "IT Professional"