Serwer wirtualizacji - prośba o porady

3

Zasadniczo nie mam konkretnego problemu, ale postaram się opisać swoją sytuację i proszę o uwagi/porady na co zwrócić uwagę, żeby cała akcja poszła jak najbardziej bezproblemowo.

Obecnie w firmie (z takich bardziej istotnych) mam 2 serwery:

  • serwer wirtualizacji, stoi na ESXi 6.0.0, wersja darmowa
  • osobna fizyczna maszyna, na której jest Windows Server 2008 R2, na nim MsSQL w wersji darmowej.

Ponieważ używany przez nas ERP z końcem roku zmienia swoje wymagania, konieczna będzie reinstalacja i aktualizacja systemu. Idąc za ciosem, chcę przenieść Win+SQL na maszynę wirtualną.

Ponieważ aktualny serwer wirtualizacji jest za stary, nie da się nowej wersji (chyba 6.5 albo 6.7) na nim zainstalować - dlatego kupuję nową maszynę.
Na niej postawię jako wirtualkę Windows 2016 i jakiegoś SQL, ale w wersji pełnej. Na razie Express sobie radzi, ale powoli dochodzimy do limitu rozmiaru bazy.

Chcę postawić NAS, który będzie robił backupy - zarówno samej bazy, jak i całej maszyny wirtualnej. Skłaniam się ku QNAP'owi - wersja rackowa 8-dyskowa, a jako soft do backupów rozważam m.in. veeam lub xopero.

Poza tym Win2016, będzie jeszcze parę wirtualek (2-3 na Windows, reszta na Linuksie), ale ten z SQL jest najważniejszy i największy.

I teraz proszę osoby z większym doświadczeniem w takim zakresie o jakieś porady i wskazanie rzeczy, na które warto zwrócić uwagę, nad którymi powinienem się zastanowić.

Pojawiła się też kwestia, czemu hypervisora stawiać na vmWare, a nie Hyper-V. Tutaj też będę wdzięczny za Wasze opinie/sugestie.

Ostatnia sprawa - czy jest sens zamiast Win 2016 Standard dać wersję 2019? Ten system ma jedynie działać jako dostawca usługi SQL, żadnych RDP itp. W necie znalazłem kilka testów, w których wygląda, że wydajnościowo 2016 wypada lepiej od 2019, więc jakie są argumenty za skorzystaniem z wersji 2019? Support nie jest argumentem, bo i tak za max. 5 lat całość będzie wymieniana.

1

Może iść z tym do chmury? Btw nie myślałeś by przenieść się na jakieś tanie linuksowe maszyny wirtualne? Przecież M$sql można odpalić na linuksie tym samym redukująć koszta licencji na windows server. Niestety od zaplecza technicznego i $$$ nie jestem dobry i nie pomogę. Z mojej strony czy zamiast kupowania fizycznej maszyny nie lepiej poszukać jakieś wirtualki i skorzystać z damarowej dystrybucji linxua?

0

zamiast kupowania fizycznej maszyny nie lepiej poszukać jakieś wirtualki

Tylko to nie będzie jedna wirtualka, ale potrzebuję ich kilka. M.in. wspomniany SQL, maszyna do obsługi drukarek fiskalnych, serwer ROON do odtwarzania muzyki w biurach, centralka 3CX do telefonii VoIP, serwer WWW+SQL do aplikacj do ofertowania itp.

skorzystać z damarowej dystrybucji linxua?

Myślałem o tym, ale tutaj akurat liczy się niezawodność i wsparcie. VMware jest produktem dedykowanym do wirtualizacji, licencja podstawowa kosztuje nieco ponad 2kpln netto, więc tragedii nie ma, a chodzi to stabilnie. Na Linuksie też da się to zrobić, ale to nie będzie wirtualizacja bare bone, tylko typu 2, chyba że chodzi o KVM, ale z tym nie mam żadnych doświadczeń. Obecny serwer wirtualek stoi już 2 lata, stawiając go nie miałem o tym zielonego pojęcia, mimo wszystko przez ten czas chodzi bezawaryjnie, po 200-300 dni uptime, żadnych problemów. Wolę troszkę zapłacić, ale mieć za to święty spokój ;)

1
Akihito napisał(a):

Może iść z tym do chmury? Btw nie myślałeś by przenieść się na jakieś tanie linuksowe maszyny wirtualne? Przecież M$sql można odpalić na linuksie tym samym redukująć koszta licencji na windows server. Niestety od zaplecza technicznego i $$$ nie jestem dobry i nie pomogę. Z mojej strony czy zamiast kupowania fizycznej maszyny nie lepiej poszukać jakieś wirtualki i skorzystać z damarowej dystrybucji linxua?

Nie każda aplikacja wspiera MSSQLa na linuxach. To, że cos za dramo, nie znaczy ze jest darmowe. Ludzie często nie liczą czasu, jaki należy przeznaczyć na instalację , migrację itp itd. W przypadku aplikacji typu gruby klient chmura wychodzi tak drogo, że lpiej kupić serwer.

1

Nie wiem czy to przydatne info ale na qnap mozesz miec serwer wirtualizacji (docker, windows, linux).
Szukaj "Virtualization Station"

0

@vpiotr: wiem, ale to za słaba maszyna, żeby udźwignęła to, co ma stać. Jakąś prostą maszynkę da się tam postawić, ale w moim przypadku to raczej nie przejdzie. Za to QNAP ma możliwość doinstalowywania modułów/aplikacji, jedną z nich jest xopero. Robi ona snapshoty całych maszyn wirtualnych. Aczkolwiek to tylko jedna z opcji i chętnie poznam Wasze sugestie

@Tomek Pycia napisał Nie każda aplikacja wspiera MSSQLa na linuxach - to po pierwsze, a poza tym nie wiem, jak wygląda to w przypadku "pełnej" wersji MsSQL. Nie bawiłem się z tym i mam średnie doświadczenie z SQL by MS.

1

Skłaniam się ku QNAP'owi - wersja rackowa 8-dyskowa

To może wykorzystasz Container Station i w docerze postawisz sobie tego SQL Server-a?

1

W sekcji enterprise qnap ma calkiem mocne maszynki, popatrz na es1681dc.
I wyglada na to ze maja dosc bogata oferte windowsowych wirtualizacji.

0

screenshot-20191030160145.png

2

@cerrato: odpowiadam w poście bo w komentarzu się nie zmieściłem...

Tak, jak pisałem do @vpiotr - obawiam się o wydajność. Zresztą nawet jeśli tego SQL by udźwignęło, to jeszcze mam kilka innych wirtualek, które łącznie na pewno by tego QNAP'a zajechały. W końcu serwer wirtualek to będzie klasa 2xE5@6core, więc nie ma co porównywać do NAS'a

Dla SQL Server najważniejszy jest RAM, wydajne IO i na końcu procesor, nie wiem który model masz na myśli, ale zamiast rewolucji w firmie, zacznij od qnapa i przenieś na niego SQL, jak się nie sprawdzi, to dobierzesz rozwiązanie oparte o dedykowany serwer do wirtualizacji.
Mam 3 instalacje SQL Servera na Qnapie (Docker, nie wirualizuje pełnych systemów) z bazami do 5 GB (na modelach z dwoma dyskami, raczej rozwiazanie do domu i małych biur) i nie mam z nimi problemów. Taka ewolucja, warto zainwestować w rozwiazanie do backapu (qnap). Wymiana serwera po 2 latach ekonomicznie nie wydaje mi się sensowna, zakładam że masz 5 lat gwarancji onsite na obecną maszynę. Skoro teraz ERP działa na 1,4 GB RAM-u i daje radę to co to będzie jak dostanie ich więcej przy pełnej wersji.
Oczywiście to zależy czy ERP korzysta tlko z silnika bazy, czy jak pisał @Tomek Pycia nie ma to w twoim wypadku zastosowania.

0

@Panczo: Twoje bazy mają po 5GB, moja powoli dobija do limitu wersji darmowej, więc jest trochę większa. Poza tym jest jeszcze druga (mniejsza) instancja do programu serwisowego, który także stoi na MsSQL. Przegadam temat stawiania SQL bezpośrednio na QNAP'ie - nie myślałem wcześniej o tym, ale może jest to jakiś pomysł :)

1

Nie chcę Ci odbierać przyjemności z nowych zabawek, w razie czego odszczekam to co napisałem ;)
A tak serio to pytanie co tam postawisz, jaki raid i ile ramu.

Druga instancja nie wydaje mi się konieczna przy pełnej wersji SQL-a.

0

Druga instancja nie wydaje mi się konieczna przy pełnej wersji SQL-a.

Jest to konieczne, bo oba korzystające z SQL programy są od innych producentów i mogą się pogryźć, jakby działały na jednej instancji (mają jakieś wymagania, nie kojarzę konkretów, ale pamiętam, że razem z ich twórcami doszliśmy do wniosku, że lepiej je rozdzielić)

A tak serio to pytanie co tam postawisz, jaki raid i ile ramu.

Ramu to pewnie 64GB, raczej powinno być OK (obecnie tyle mam i zużywana jest tak 1/3, ale nie ma na wirtualkach SQL). Co do RAID - jedyny słuszny/prawilny, czyli RAID6 :)

0

skoro ustalałeś z producentami systemów to nie będę komentował nie znając szczegółów

Ramu to pewnie 64GB, raczej powinno być OK (obecnie tyle mam i zużywana jest tak 1/3, ale nie ma na wirtualkach SQL). Co do RAID - jedyny słuszny/prawilny, czyli RAID6 :)

Tylko że Express to max 1,4 GB na instancje, przy pełnej wersji na 10 GB bazę SQL, pobierze trochę wiecęj, skoro teraz masz 2/3 wolnej, to moim zdaniem spokojnie to uciągniesz na tym QNAP-ie

0

Tylko że Express to max 1,4 GB na instancje

Ale powtarzam - poza SQL, będzie tam jeszcze parę innych wirtualek postawionych. Jakby jedynie chodziło o SQL to sprawa by była czysta, ale na tym hypervisorze ma być ok. 10 maszyn postawionych, z czego ten wałkowany przez nas SQL jest tylko jedną z nich.

0

ALe je piszę o rozwiązaniu w którym pozbywasz się fizycznej maszyny z SQL Server i przenosisz na QNAP-a, ktorego kupujesz do robienia backpów w firmie. Serwer (ten z ESXi) pozostawiasz bez zmian.

Chyba, że QNAP tego nie pociągnie wtedy zmieniasz na nowy serwer, a nie, że wszystkie wirtualki ładujesz na QNAP-a

2

No tylko skoro i tak będzie serwer wirtualek, to jaki jest plus wrzucania SQL na QNAP'a, a pozostawianiu reszty na wirtualkach? Temat zbadam, ale pierwsza myśl jest taka, że w razie jakichś problemów to jednak łatwiej jest pogrzebać na "prawdziwym" Windowsie, niż szukać gdzieś na dockerze stojącym na serwerze plików. Jeśli bredzę, to proszę o sprostowanie ;)

2

To się chyba rozmineliśmy, z pierwszego posta zrozumialem, że aby podnieść wersje SQL-a musisz zmienić cały serwer ESXi, a przy okazji dokupić QNAP-a do backup-u.
Obecny serwer ESXi ma 2 lata (i jak domniemuje jest jeszcze na gwarancji).

Więc ja wyszedłem z zalożenia ekonomicznego, że nie ma sesnu wymiana całego serwera do wirtualizacji tylko po to by podnieść wersje bazy danych. Wykorzystaj nowego QNAP-a do tego.

Zresztą czegoś nie rozumiem:

Nie mozesz zrobic upgrade'u do 6.5/7 bo serwer jest za stary skoro ma 2 lata to zakładam że masz wersjie ESi 6.0, skoro dodatkowo piszesz o RAM : `obecnie tyle mam i zużywana jest tak 1/3, ale nie ma na wirtualkach SQL), to dlaczego nie dołożysz wirtualki z Windowsem, w końcu 6.0 wspiera Windowsa 2019:

https://www.techcrumble.net/2019/02/windows-server-2019-compatibility-for-esxi-6-5-and-6-0/

Co pominąłem?

0

@Panczo: to się nie dogadaliśmy, już wyjaśniam/prostuję

  1. obecny serwer nie jest na gwarancji. Kupiłem używkę za śmieszne pieniądze, żeby w ogóle się pobawić wirtualizacją, zobaczyć jak to działa, sprawdzić czy to się przyda i nabrać jakiegoś doświadczenia. Założenia były takie, że potem albo zrobię to porządnie (na lepszym sprzęcie), albo sobie odpuszczę. Obecnie jest to maszyna IBM 3850 (coś w stylu https://computerowiec.com.pl/cat15746/56-ibm-x3850-m2-4x213-qc48gb2x1tb2x73raidcombo.html), z 4x4core Xenon i 64GB RAM.

  2. QNAP do backupów i tak musi być, obecnie kopie mamy robione metodą partyzancką (aczkolwiek dającą radę), ale kopiowana jest jedynie baza, a nie cała maszyna

  3. Teoretycznie mogę postawić nowszego SQL na obecnym Win2008R2, ale ilość zamieszania z tym związanego jest zbliżona do postawienia nowszego serwera razem z nowym SQL. Póki co jeszcze mógłbym korzystać z darmowego SQL, ale za chwilę skończy się limit miejsca na bazę, więc już chcę to zrobić porządnie i w sposób, który zapewni mi święty spokój na najbliższe kilka lat

  4. co do wersji ESxi - i tak muszę kupić pełną wersję, bo darmowa nie obsługuje backupowania maszyn. Teoretycznie są programy, które to obchodzą i potrafią robić coś w rodzaju snapshotów, ale wyniki ich działania są dalekie od oczekiwań. W szczególności czas działania - Windows7 z przydzielonym miejscem 60GB na dysk robiło jakieś 2-3 godziny. Dlatego muszę mieć wersję płatną, która już zapewnia całe API do backupowania. A skoro płacę, to chcę mieć wersję najnowszą. A najnowsza nie pójdzie na moim obecnym sprzęcie (powtarzam - nie ma on 2 lat, a jedynie od 2 lat jest u mnie).

Czy teraz lepiej wytłumaczyłem, jak sytuacja wygląda, czy nadal coś jest niejasne? Jakby co to śmiało pytaj, chętnie wytłumaczę ;)

1

Teraz wszystko jasne ;)

W takim razie nie ma sensu ładować kasy w wypasionego QNAPa, nie jestem obeznany w ofercie produktowej QNAP-a, ale podejrzewam, że ten z możliwością rozbudowy do 64 GB RAM to będzie spory koszt. Lepiej mieć faktycznie serwer pod wirtualki i osobną maszynę pod backup.

2

No dobra, a gdzie ten ESX będzie trzymać dane? Chcesz mieć macierz na dyskach wewnątrz serwera czy macierz jako osobne urządzenie?
Do tej pory korzystałem z pierwszej opcji (ale to raczej z powodu budżetu) i widzę sporo wad tego rozwiązania. W szczególności czasochłonne kopiowanie/przenoszenie wirtualek pomiędzy kilkoma serwerami ESX. Przy datastore współdzielonym przez różne maszyny jest już dużo łatwiej.
Poza tym pojemność macierzy jest limitowana liczbą slotów w serwerze i tego nie przeskoczysz. A drugą macierz zawsze można dołożyć, zresztą zwykle mają więcej slotów na dyski niż serwer.
Niezależnie od rozwiązania, zastanów się mocno (a jeśli masz możliwość po zakupie - to zrób też testy) nad podziałem macierzy na dyski logiczne. Raczej odradzam dzielenie macierzy na więcej niż jeden dysk logiczny, jeśli masz tylko minimalną liczbę dysków dla danego poziomu RAID (np. dla RAID-5 - 3 dyski). Niby lepiej, gdy system ma dostęp przez osobne urządzenia logiczne, ale co z tego skoro fizyczne dyski są wspólne. Raz tak zrobiłem i żałuję, a zmienić to teraz trudno. Każda maszyna wirtualna intensywnie zapisująca dane zauważalnie spowalnia pozostałe, nawet jeśli korzystają z innego dysku logicznego.
Jest taki obraz wirtualki ESX, który pozwala na różnorodne testy dysków, warto poeksperymentować przed ostatecznym wyborem sposobu podziału dysków na macierze, a macierzy na dyski logiczne:
https://flings.vmware.com/i-o-analyzer
Nawet jak na to poświęcisz tydzień, to warto - lepsze to niż potem latami czekać na możliwość wyłączenia maszyn i reorganizacji dysków. :)

0

Co do trzymania danych - myślałem o zewnętrznej macierzy, ale jest to dodatkowy element, który może spowodować problemy. Wystarczy, że macierz się zwiesi, albo nawet jakiś kabelek z karty wysunie i całość leży. Oczywiście - nie będzie się to działo często, ale jest to jakieś dodatkowe miejsce do powstania awarii (poza tym kwestia wydajności - wydaje mi się, że RAID na SSD fizycznie wsadzony w maszynę będzie chodzić lepiej, niż coś zewnętrznego).

W temacie trzymania danych na osobnym NAS - owszem, jeśli chcesz mieć kilka serwerów (czy jakiś klaster, czy nawet ręcznie przełączanych w przypadku awarii) to rzeczywiście jest to dobry patent, ale u mnie będzie jeden serwer, więc nie ma takiej potrzeby.

Zauważ, że pisałem o backupowaniu całych maszyn. Będzie robiona zarówno kopia samej bazy, jak i snapshot wirtualki, więc w razie awarii można po prostu przywrócić maszynę (czy fizycznie an tym samym serwerze, czy na innym) w chwilę.

Nie chcę się bawić w dzielenie fizycznie dysków na jakieś woluminy logiczne (jeśli jestem w błędzie to proszę o wyjaśnienie), po prostu robię RAID 6, na nim instaluję ESxi, a cała dostępną przestrzeń przydzielam jako główny datastore.

1

Zewnętrzna macierz to przede wszystkim koszt. :) A możliwości ma zwykle większe niż kontroler dysków w serwerze. Tego się nie dotyka, więc wypadające kabelki hmm... Nie powinno to stać w kuchni ;) Na jeden serwer faktycznie może być to zbyt wiele, szczególnie jeśli nie masz terabajtów danych.

Z woluminami logicznymi chodziło mi o to, że najpierw tworzysz macierz RAID na N dyskach, a potem możesz albo stworzyć jeden dysk logiczny (o pojemności 100% macierzy) albo wiele.
Jeśli masz możliwość i wystarczająco wiele slotów na dyski, to zrób raczej osobne dyski na system (np. 2 dyski w mirrorze), a z pozostałych zrób RAID na datastore.

0

Kolesie, z którymi być może będe temat realizować (na razie się waham, czy robić to we własnym zakresie, czy zlecić całościowo usługę firmie z doświadczeniem w takich tematach) sugerują postawienie systemu na kartach SD. Dla mnie to była prowizorka, ale oni twierdzą, że tak się robi, że producenci serwerów oraz VMware tak zalecają. W ten sposób sam system jest na 2 kartach SD, a dysk jest w 100% (pisząc "dysk" mam na myśli RAID) przeznaczony na dane.

Czy ktoś miał z Was z czymś takim styczność?

1 użytkowników online, w tym zalogowanych: 0, gości: 1