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



28.06.2017

Core i9 – nowa seria...

Intel Core i9 Skylake-X i Kaby Lake-X
23.06.2017

Z autotrackingiem

Aver PTC500
20.06.2017

Do budynków i na zewnątrz

Ubiquiti UAP-AC-HD
16.06.2017

Monitor 16:3

BenQ BH281
13.06.2017

Monitorowanie

Axence nVision 9.2
12.06.2017

Exatel Security Day –...

Już 20 czerwca w Warszawie rozpocznie się druga edycja Exatel Security Day. W tym roku...
09.06.2017

Automatyzacja...

Red Hat Ansible
06.06.2017

Optymalizacja wydatków

Snow for Office 365
01.06.2017

Zarządzanie końcówkami

baramundi Management Suite 2017

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"