Case Study QNAP bardziej przydatny wirtualnym maszynom na ESXi niż ESXi QNAP'owi

[Silas Mariusz]

Nie od dziś wiadomo, że wirtualizacja zdezorientowała świat IT do tego stopnia, że sam Microsoft zmuszony był zmodyfikować treści swoich licencji, a firmy outsourcingowe i hostingowe zarabiając na nowym sektorze IT nieświadomie spopularyzowały erę tzw. cloudingu - chmury.

Niewątpliwie liderami tej technologii jest niepodważalny Citrix demonstrujący w 2006 roku wirtualizowane aplikacje Microsoft Word i Excel 2007 w przeglądarce beż żadnego pulpitu i systemu w Ajaxie daleko przed premierą HTML5. Kolejnym po Citrixie, ale za to bardziej popularnym jest VMware stepujący niestety ich krokami. Obu z nich, a także Microsoft od dawna są licencjonowanymi i certyfikowanymi partnerem storage'u dla każdych dziś serwerów QNAP.

I pomimo świetnego skalowalnego produktu wspominanych firm, muszę stanąć i obronić tu najmłodszego i właściwie ulokowanego w innym segmencie IT - producenta serwerów QNAP. Dzięki bezpłatnej wirtualizacji KVM w serwerach TurboNAS w segmencie SOHO oraz średnich i małych firm, QNAP wydaje się najrozsądniejszym i najbardziej ekonomicznym wyborem zapewniającym bezpieczeństwo i łatwą administracje umożliwiając wystarczające aż zanadto możliwości.

Już słyszę w Waszych głowach "co on ...?". Zechcecie mnie zlinczować, bo przecież jak mogę podważać autorytet ESXi vSphere i pisać jaki to KVM na QNAP'ie jest wspaniały. Niestety artykuł, który czytacie lata na forum postawionym na jednej z takich maszyn w DataCenter w FR i uruchomionym ESXi 6.0.

O to ESXi 6.0. Ładny prawda?

Teraz wyobraźcie sobie taki scenariusz....
Jedna z maszyn ma wielkość 350GB, na której pracuje Linux Ubuntu z panelem hostingowym (dawniej Plesk) Odin. Co to oznacza? A to, że lata na nim więcej niż tylko forum na którym czytacie ten artykuł:

Co się stanie jak to wszystko ulegnie awarii?

• serwer DNS przestanie odpowiadać (tak, wiem... sprzedawca dedyka chojnie obdarował Was secondary DNS'em - szkoda, że w przypadku awarii serwera w niczym on nie pomoże)

... co dalej?

• brak poczty e-mail sparaliżuje kilka firm i ich kontakty handlowe oraz transakcje,
• brak strony internetowej narazi na straty potencjalnych klientów oraz uniemożliwi zweryfikowanie i dokonanie bieżących transakcji.

....nazywa się to katastrofa, okrzyknięta słowami prezesów na "k", a u odpowiedzialnej nazywanej od tej chwili pseudo-adminem wyrywaniem włosów z głowy.

Jak zapewne się domyślacie zaraz będę tu reklamował QNAP'a. I macie racje.

Oczywiście VMware jak i Citrix nie został zaprojektowany do tak amatorskich celów jakie opisywałem czyli stawianie jednego hosta, aby zapewnić ciągłą pracę w przypadku awarii. Aby tak było, trzeba zbudować klaster i HA, a za tym idą koszty i dodatkowa jednostka do scentralizowanego zarządzania. OVH i ich usługi VPS bez backup są świetnym przykładem jak klaster nawet nie zabezpiecza Waszych danych. Sam zakup dedyka pod jedną wirtualkę również należy do najgłupszych pomysłów, bo backup nie wygląda tak fajnie jakby Wam się wydawało.

1. Backup pojedynczej maszyny jest wykonywany manualnie przez skrypt lub z automatu, ale...
2. Backup podczas nieprzerwanej pracy maszyny z bazą SQL, może narazić nas na nieodwracalne jej uszkodzenie spowodowane brakiem spójności brakujących danych, które wisiały w Cache'u
3. ... bo jak wiadomo backupuje się maszynę ale nie jej RAM
4. Nie ma tu mowy o archiwizacji przyrostowej, więc za każdym razem musicie pchnąć po NFS'ie 350GB maszyny - a prawda jest taka, że mając do dyspozycji symetryczne łącze z gwarantowanym 30mbit tylko jej sam backup będzie trwał ~25 godzin.
5. ESXi nie dysponuje serwerem HTTP, który potrafi zrobić resume przerwanego tak dużego pliku, a nawet jeśli to zrobi to uwierzcie będzie on uszkodzony.

Dobra zrobicie tak jak ja na początku i postawicie kolejną wirtualkę, do której wrzucicie kontener i dzięki QNAP'owi uda się ona na zasłużony błyskotliwemu adminowi rsync.
:glupi:
- oczywiście, że kłamie. Przecież to najgłupszy chyba możliwy pomysł.

W jaki sposób QNAP może przyczynić się do zabezpieczenia takiej instalacji?
ESXi to nie vSphere, a kopia zapasowe jego maszyn jest na wagę złota. Nie bez powodu tą kwestię rzuciłem (chyba) najlepszemu specjaliście jakiego znam, który nie idzie śladami marketingowymi a własnym doświadczeniem:

16:59:45 Silas: no dobra, ale raid w ESXi
16:59:55 Silas: myslisz ze to dobry pomysl ?
16:59:59 rithien: nie wiem
17:00:03 rithien: nie uzywalem
17:00:06 Silas: wlasnie...
17:00:14 Silas: z deszczu pod rynne
17:00:18 rithien: noo
17:00:25 rithien: to lepiej juz hw raid
17:00:27 rithien:
17:01:03 Silas: k...
17:01:07 rithien: i wlasnie dlatego musialem uzywac proxmoxa
17:01:08 Silas: to juz wolalbym zainstalowac Proxmoxa
17:01:12 rithien: buhahah
17:01:12 Silas: heee

Zatem QNAP proponuje nam dwa wyjścia z takiego scenariusza. W obu skorzystamy z oferowanej stacji wirtualizacji, która posłuży albo jako backup, albo rzeczywiście do serwowania tego samego eliminując kłopot taniej wirtualizacji.

Rozwiązanie nr. 1
Serwer dedykowany oraz ESXi pozostaje niezmienione.
Planowane są dwa rodzaje kopii zapasowych:

• Pełna: Raz na miesiąc z crontab'a w esxishellu wyzwalana jest ich kopia ghettoVCB.sh po przyłączanym na żądanie datastore po NFS do lokalnie uruchomionego w firmie QNAP'a.
• Indywidualna przyrostowa wew. każdej maszyny: Aby zapewnić aktualne dane w tym pocztę, bazę SQL, strony Web oraz inne ważne dane uruchomiona za pierwszym razem każda z maszyn dostaję przyrostową kopię danych każdego dnia za pomocą dostępnej w QNAP'ie lub zainstalowanej manualnie aplikacji BackupPC.
  (Ref.: How-To - Jak wykonać kopie zdalnej maszyny Linuxowej za pomocą BackupPC?)

W przypadku awarii, kierowane są domeny na FailOver serwery uruchomiony w stacji wirtualnej.

Rozwiązanie nr. 2
Wykorzystujecie serwer QNAP to celów zaawansowanych w tym wirtualizacji.
Fakty:

• Dysponując łączem 30mbit poradzicie spokojnie sobie z małym hostingiem oraz serwowaniem małych treści i witryn internetowych
• Jeśli łącze, którym dysponujecie ma słaby routing a klienci zgłaszają wolne działanie strony, to znacznie lepiej będzie wesprzeć Wasze strony CDN'em na cały glob dzięki usługom Amazon lub CloudFlare
  
  
• Uruchomienie maszyn, tj. Ubuntu z Odinem nawet umożliwi Wam możliwości tj. home.pl a w trybie resellerskim ich konkurencję
• Dzięki możliwej lokalnie administracji i konfiguracji RAID odpowiedzialnie zabezpieczycie przechowywane maszyny wirtualne
• Lokalny zapis umożliwi szybki backup
• W przypadku nieprzewidzianej awarii dysków ich odzyskanie i przywrócenie będzie możliwe za pomocą PC
• W krytycznym wypadku awarii serwera czy nawet jego zasilacza bez żadnego problemu przyłączycie dyski do PC i w VMware Workstation lub VirtualBox'ie przywrócicie działanie infrastruktury

Jak ja to robię?

A jak Wy byście zrobili?
umny:

 

[mariuszsal]

A jak Wy byście zrobili?

Proste. Drugi dedyk i HA