Strony

sobota, 4 września 2010

esxi standalone - często popełniane błędy

Wielu z moich znajomych obsługujących firmy z grupy "małe-średnie", przesiada się na darmowe VMware ESXi, jako powody podają:
  • łatwiejsze zarządzanie maszynami
  • utylizacja mocy procesorów
  • zgodnie z powyższym - redukcja zbędnego sprzętu
  • możliwość łatwego (ręcznego) przenoszenia maszyn pomiędzy hostami na wypadek awarii
  • uproszczenie infrastruktury
Niestety - w ramach migracji, instalacji, popełniają schematyczne i często te same błędy. Błędy zarówno koncepcyjne jak i konfiguracyjne. Kilka - które mi się przypominają postaram się opisać i "rozwiązać" (w miarę łopatologicznie).


  • "przeniosę kilka niezależnych maszyn fizycznych, świadczących różne usługi sieciowe i uruchomię na jednym hypervisorze" - no i tutaj mamy błąd koncepcyjny: o ile byłeś w stanie wyobrazić sobie swoją infrastrukturę w momencie awarii jednego z tych serwerów, musisz wyobrazić sobie co stałoby się - jakby awarii uległy wszystkie na raz (czyli pada hypervisor). To co kiedyś opisywałeś jako "disaster" (pada kilka maszyn fizycznych świadczących różne usługi), teraz jest dość prawdopodobne i Twój "mało prawdopodobny scenariusz" staje się kwestią ubicia jednej maszyny.
  • "robię backupy snapshotami" - snapshot to nie backup, backup snapshota - to nie backup (tutaj - patrz rozwinięcie :) ). Doświadczenie wskazuje na dwa pomysły: 
- "zrobię snapshot działającej maszyny wirtualnej i zrobię backup snapshota". OK - masz "backup" - jak każdy backup - dobrze byłoby przetestować jak zadziała. Jest to dla przykładu (przykład nieprzypadkowy) - MAŁY serwer bazodanowy... jeśli wcześniej nie załapałeś - to może teraz zaświeciło się światełko "co z rozpoczętymi transakcjami, co z połączeniami będącymi w stanie established" w końcu czy baza zachowa konsystencje? Nie sądzę, by po padzie maszyny - jakikolwiek podłączony klient zaczekał aż Ty przywrócisz snapshot sprzed kilku dni - i dokończy poprawnie posiadane połączenie :)
- "rozumiem powyższe, wiec zrobię snapshot wyłączonej maszyny" - lepiej, ale nadal pozostaje kwestia co z maszyny jest krytyczne, a co backupujesz dla "funu". Jeśli maszyna jest np fileserverem - to snapshot - daje Ci dużo zbędnego narzutu na trzymane dane (w postaci systemu operacyjnego wraz z temp'ami, i innymi śmieciami)
- Wniosek: snapshoty rób by unikać błędów update/upgrade oraz by mieć stan jakiejś maszyny na wypadek niepowodzenia czy błędów samego systemu operacyjnego. Backupuj - konfiguracje i pliki serwera na poziomie plików w guescie a nie wirtualnych maszyn w hypervisorze.

  • HCL (Hardware Compatibility List) - coś co zostało stworzone przez vmware - byś mógł wiedzieć czy dane rozwiązanie zadziała na sprzęcie który masz. Niestety (tak!) ESXi działa również na innym sprzęcie (nieoficjalna lista). Dlaczego niestety - bo kusi by zainstalować go "produkcyjnie" na czymś niesupportowanym. Pamiętaj więc - że o ile rozwiązanie postawione na niesupportowanym sprzęcie może działać wieki poprawnie, może się zdarzyć, że przestanie działać nagle, bądź po update/upgrade hypervisora. Zresztą - nawet supportowany sprzęt bywa "uwalany"... patrz mój wcześniejszy post.

  • upgrade hypervisora - im więcej krytycznych usług trzymasz na jednym hypervisorze - tym więcej musisz położyć w momencie upgrade. Niestety - ESXi standalone przy upgrade - wymaga zatrzymania wszystkich maszyn fizycznych. Niejednokrotnie spotkałem się np z przypadkami gdy zatrzymanie maszyn wyłączało np. DNS'a, a ten do upgrade się przydaje :)
  • sieć wirtualna - vswitch'e - wiem, że ciężko to czasem ogarnąć, ale na wstępie, warto oddzielić management network od sieci korporacyjnej, w większości przypadków - niestety management network - z wygody działa z adresacją i logiką taką jak i cała sieć lokalna - co nie jest ani bezpieczne ani porządkogenne :). Kolejny fakt, na który warto zwrócić uwagę - to wydajność interface ethernetowego. Nawet posiadając kiepski nie HCLowy sprzęt - warto zainwestować w markową kartę sieciową z własnym procesorem. Podkreślić muszę - że przez ten/te interface będzie chodzić ruch kilku maszyn virtualnych - ruch, który kiedyś musiało obsłużyć kilka portów switcha fizycznego przechodzi teraz przez jeden port karty sieciowej (btw. trunking jest bardzo mile widziany :) ). Będąc już przy temacie swichy fizycznych - niestety - tutaj również, trzeba mieć sensowny (najlepiej markowy, zarządalny) switch - który będzie w stanie znieść dość duże I/O na jednym porcie (zamiast wcześniejszych kilku). Doświadczalnie - DLinki i inna chińszczyzna, przy kompensacji usług na jednym porcie - zapychają się jak pielucha w kiblu :)
  • management station. Pierwsze - mało oczywiste dla niektórych - nie może to być maszyna wirtualna (patrz pkt - upgrade hypervisora). Drugie - ta maszyna powinna stać w infrastrukturze (a nie jak robią niektórzy być klientem na laptopie administratora). Dodatkowo - nie powinno być na niej cuda wianków i usług dodatkowych. Wszelkie usługi monitorujące, backupujące itp.  - na osobnej maszynie. Unikniecie wtedy problemów z upgrejdami.
  • "o! mam pendrive 2GB, zainstaluje na nim esxi" - tak, zainstalujesz - będzie działać... tak mniej więcej do pierwszego updrejdu bezproblemowo. Przy pierwszym upgrade, braknie Ci miejsca na scratch'u, chyba, że wcześniej skończy się w syslogu. Bo syslog i scratch partition, to dwie usługi - które zabijają pendrive 2GB (zalecane przez vmware - 4GB) - przeniesienie syslog'a i scratch'a na datastore - gwarantuje sukces... co notabene opisane jest w dokumentacji - tak - tej której nikt nie czyta, a imho ten 103 stronicowy dokument jest pozycją, bez której nie ma się co tykać ESXi.
  • switchy wirtualnych się nie łączy :) - można zwiększyć liczbę portów! Tworzyć switche - najlepiej z commandline (unikniemy wtedy dowolności vmware w dobieraniu portów)
  • dyski sata - ich wydajność - NIE POZWALA na stawianie rozwiązań produkcyjnych na nich właśnie. Pomijam pomysły typu "postawienie kilku wirtualek na pojedynczym dysku sata" - bo to już jest samobójstwo. Jeszcze dopuszczalnym uważam macierz typu raid10 pod hypervisorem, niemniej jednak - trzeba brać poprawkę na to, ze jak będzie trzeba wymienić pojedynczy dysk, to rebuild raida popsuje nam wydajność całego hypervisora - i to dość konkretnie.
  • auto startup - ma swoje "zady i walety", jedną z zalet - jest fakt, że można "włączyć hipervisora i iść do domu"... wadą natomiast jest to, że nie będąc a maintenance mode zrobimy "szybki reboot" - to szybki będzie oznaczać reboot + startup maszyn + shutdown maszyn. Generalnie się nie opłaca. Można wyklikać sobie bez problemu skrypt w vicli - który uruchomi nam wszystkie wirtualki jedna po drugiej.

3 komentarze:

Borys Łącki Bothunters.pl pisze...

Bardzo trafna uwaga o Single Point Of Failure. Mało kto o tym pamięta i wszyscy radują się zawzięcie, że posiedli we władanie wirtualizację :]

Leszek Miś pisze...

Wirtualizacja powinna być wykorzystywana z umiarem - to fakt. Niestety w rzeczywistości oszczędza się na czym tylko możliwe - kosztem np. braku dostępności usług podczas awarii hypervisora. Prawda jest taka, że wszystko zależne jest od krytyczności usług i oczywiście podejścia biznesowego Klienta.

Nadal jednak pasuje tutaj powiedzenie "zawsze coś za coś".

marcinbojko pisze...

Czyli nie jest ze mną tak źle, skoro z checklisty nie reguję jedynie na sugestię tworzenia vswitchy w cli? Resztę w zasadzie mam już przećwiczone na bólach i znojach żywych (lub już nieżywych) organizmów.