Witam.
Czy jest możliwe zbudowanie RAID 1 z dwóch dysków M2 PCIE i startowanie systemu Windows Server 2019 z takiej konfiguracji? Jeszcze tego serwera nie kupiłem, i takiej konfiguracji nie mam, dlatego nie mam jak spróbować, a od tego zależy czy wezmę normalny kontroler sprzętowy i dyski ssd sata czy M2. Jeśli się da, to jak to zrobić optymalnie? Dyski planuję po 2x500GB, na tym partycje pod system, i partycje pod pliki baz MS SQL.
Do firmy bym odradzał, bo nawet jeśli działa pewnie nie ma hotswapa.
Priorytetem jest wydajność SQL i bezpieczeństwo danych. Przestój np pół godziny w sytuacji awarii dysku jest do przyjęcia. Taka awaria nie zdarza się często. Utrata danych od ostatniego backupu byłaby zdecydowanie gorsza.
Jak to jest dla Ciebie priorytetem, to startuj OS nie z M.2 a z innych dysków a M.2 zrób pod SQLa.
To z dodatkowym dyskiem systemowym też jest jakieś rozwiązanie, o ile pod systemem jakoś zbuduję RAID z tych M2. Nie widziałem jeszcze na oczy Windows Server 2019 więc może moje pytania są o oczywiste rzeczy. Muszę chyba jednak poćwiczyć na jakimś trialu i wirtualce.
2019 szczególnie nie różni się od 2016. Co do kupna serwera: raczej idź w kontroler sprzętowy a nie na poziomie OSu. Możesz spinać w OS w RAID, ale jak Ci zależy na wydajności, oraz prostocie zarządzania to raczej kontroler sprzętowy.
No i skup się na licencjonowaniu:
– czy w środowisku masz lincencje CAL
– czy masz licencje na CAL MS SQL (jak to ‘pełen’ SQL),
– jaki SQL,
– jak będziesz go backupować i gdzie.
Ostatnia moja styczność z Windows Server to 2008, RAIDów nigdy nie robiłem pod Windows. Nie wydaje mi się, aby kontroler z dwoma dyskami SATA był wydajniejszy niż raid 1 softowy z dwóch dysków M2, no ale może tak skopali to w Windows, że jednak…
CALe do Windows kupuję, do SQL mam bo zostaję przy tej wersji co mam teraz (2014). Niestety upgrade jest drogi, więc jeszcze musi poczekać. Backupy mam opanowane.
Co do licencjonowania, to jednej rzeczy nie jestem pewien, bo trafiałem na sprzeczne informacje.
Nie przytoczę teraz linka, bo nie pamiętam gdzie to było, ale znalazłem, że w ramach licencji Standard mogę mieć uruchomione 2 wystąpienia systemu operacyjnego. Rozumiem, że może to być pełne 1 wystąpienie fizyczne i pełne 1 wirtualne pod nim? bo znalazłem też, że mogą być 2 pełne wirtualne i jedno fizyczne niepełne czyli jako host wirtualek, a w starszych edycjach podobno było 1 niepełne fizyczne bo tylko jako host wirtualek, i 1 wirtualne, i niektóre źródła nadal się tego trzymają.
Co do dysków: nie chodzi o wydajność, tylko jak Windows zarządza RAIDem, awaria itd. Kontroler sprzętowy zapewni Ci więcej spokoju przy wymianie dysku.
Wirtualizacja: możesz mieć dwie instancje Windows 2019 “produkcyjne”, tj.
1/ stawiasz np. Windows 2019 Standard (z kluczem) i na nim instalujesz Hyper-V
Będzie to służyć tylko i wyłącznie jako hypervisor typu pierwszego, nie możesz tam instalować żadnych usług typu udostępnianie plików, DNS itd. Tylko i wyłącznie wirtualizator
2/ Stawiasz VM1 Windows Standard (z kluczem)
3/ Stawiasz VM2 Windows Standard (z kluczem)
Czyli: użyłeś klucza trzy razy, ale masz pełnoprawne dwie VM Windows 2019 Standard.
Sprzętowy RAID zawsze będzie lepszy niż software’owy. W wydajności nie będzie jakiejś kolosalnej różnicy, ale w razie czego odbudowa windowsowego RIAD-u na pewno będzie dużo wolniejsza. Windowsowy nie wspiera też hot-swap, tzn. trzeba wyłączyć maszynę (choć przy dyskach M.2 NVMe i tak trzeba).
A tak w ogóle to ten SQL Server będzie działał na fizycznym serwerze czy w maszynie wirtualnej?
Pełna zgoda, że łatwiej będzie w razie czego, na fizycznym kontrolerze, ale chodzi o wydajność. Nie kupując dedykowanego kontrolera, mogę te pieniądze przeznaczyć na np RAM, i kupić 128GB zamiast 64GB, a dodatkowo dyski M2 powinny szybciej pracować. Ale zaraz, czyli funkcjonalność RAID w Windows jest tak zła, że nie można na niej polegać? Jakoś pod Linuxem to działa…
Co do drugiego pytania, to jasne jest, że mogę mieć 2 pełne instancje wirtualne + wirtualizator. Natomiast nie znalazłem, czy mogę mieć 1 normalną, pełną, fizyczną instancję z usługami + 1 wirtualną instancję (dodatkową, do czegoś małego). Czyli też dwa pełnoprawne systemy, ale jeden fizyczny, a drugi wirtualny, a nie oba wirtualne. SQL zamierzam zainstalować na fizycznej, chcę mu przydzielić jak najwięcej RAM, ma wymiatać. Wydaje mi się, że SQL na fizycznym systemie pozwoli mi uzyskać większą wydajność niż na wirtualnym. Z drugiej strony, zajmuję się troszkę inną dziedziną IT a nie serwerami (zwłaszcza z Windows) więc może jednak planuję coś źle.
I tak powinieneś zrobić. Przecież SQL wykonuje operacje w RAM i tyle ile jest w stanie to bierze.
Zamiast wymyślać, postaw Windows Server 2019 nawet na zwykłych talerzach, po co Ci m.2 pod system, który startuje raz na jakiś czas? Co Ci da, gdy raz w miesiącu system wstanie Ci po minucie, a nie 40 sekundach?
I tak dłużej będzie trwał POST, który zajmuje 2 do nawet 5 minut. W mojej opinii stawianie WS na m.2 nie ma kompletnie sensu. Pod SQL jeszcze rozumiem, ale RAM dla SQL również jest ważny. Tak więc, daj te 128GB RAM i SSD tylko pod SQL.
Jak w ogóle wygląda sieć gdzie ma stać ten serwer? Fast Ethernet, GigabitEthernet, a może 10 GigabitEthernet?
Czy system będzie czy nie na tych M2 to nie jest takie istotne, ważne aby SQL miał szybki dostęp do danych, i aby te dane były bezpieczne. Sieć jest gigabitowa. Obciążenie bazy ruchem nie jest duże, tylko niektóre operacje zajmują dużo czasu, robi się lock na tabeli, do tego to się wykonuje tylko w jednym wątku, i wszystkim aplikacja wisi.
Przećwiczyłem na wirtualce ten windowsowy raid. W zarządzaniu dyskami zrobiłem “Dodaj dublowanie” i wystartowałem z drugiego dysku po odłączeniu pierwszego. Zadziałało, natomiast w bootmanagerze musiałem użyć pomocniczego obiektu plex aby wystartowało. Odłączyłem też dysk podczas pracy systemu, wówczas nic się nie stało, dysk w menedżerze pojawił się jako Nieodczytywalny, ale system pracował dalej. Po restarcie miałem pomocniczy plex do pomocniczego plexu, ale działało. Wygląda na to, że powinno działać.
MS SQL na wstępie bierze tyle, ile jest RAM w OS, to oczywiście trzeba skonfigurować i zostawić coś dla OSu, ale nie o tym.
To, że MS SQL wykorzorystuje bardzo dużo pamięci nie oznacza, że nie korzysta z podsystemu dyskowego:
-tempdb, ale tam jest zapis sekwencyjny, więc jakieś 15k HDD jest ok,
- logi transakcyjne, do nich zasuwa się bardzo dużo zapisów.
W 2021 trzymać plik bazy, index, log transakcyjny na dysku talerzowym (nawet w RAID0) nie jest optymalnym rozwiazązaniem.
Kompromisem tutaj będzie:
– postawienie Hypervisora na jakiś wolniejszych dyskach (niech sobie nawet będą na zwykłych SATA w RAID1),
– trzymanie maszyn wirtualnych na SSD.
Ale przecież cały czas piszę o stosowaniu dysków M.2 PCIe NVME i zrobienie windowsowego raidu 1 na nich. Dyski M.2 mam na myśli SSD. Nie wiem czy w ogóle są dyski M2 talerzowe, ale chyba nie. Planuję na M.2 zrobić system + bazy. Jeśli system nie będzie chciał z tego startować, to go zrobię na SATA, ale wszystko związane z SQL chcę na M.2.
Tak, wiem że przydział RAM trzeba ustawić i że dysk również wykorzystuje. Dlatego uważam, że lepiej posadzić system na talerzach, pod SQL dać SSD i RAM.
@qbpm dlatego pisałem, że lepiej te pieniądze zainwestować w SSD i RAM pod SQL. Mam kilka konfiguracji, gdzie system jest na SSD SATA i bazy również na SSD i kilka gdzie system jest na talerzach, tu co prawda są SAS i nie ma tu wielkiej różnicy. Zwłaszcza że serwery i tak uruchamiają się długo.
A czy przeszkadza użycie tego samego dysku SSD na system jak i na SQL? System obciąży ten dysk w znikomym stopniu. Rozdzielenie na osobne dyski system i osobno SQL podnosi koszty i komplikuje troszkę sprawę, dlatego chciałbym poznać uzasadnienie tego rozwiązania. Może nie jest to jakaś duża komplikacja, ale tak czy siak na ten moment nie widzę żadnego sensu tak robić, dlatego pytam. Jedyne co, to podzieliłbym na partycje, osobno system, osobno bazy.
A mają koledzy jakieś propozycje co do dysku M.2 pod SQL? Jak wiadomo, przepustowość M.2 jest pięciokrotnie wyższa od SATA, dlatego M.2. Jeśli ktoś jednak zaproponuje SATA, to proszę o jakieś mocne uzasadnienie w czym SATA będzie lepsze od M.2. O dysku talerzowym proszę nawet nie wspominać 
Nie przeszkadza, jeżeli wystarcza Ci miejsca. Np. partycja 100 GB na WinSvr + SQL Server, 400 GB na dane.
Tak z ciekawości: duże te bazy?
PS Dyski talerzowe nie są takie tragiczne - o ile jest to SAS 15k 6Gbps 
Tak jak pisałem wcześniej: Brak hotswapa. A jak jest brak hotswapa, to brak produktów storage odpowiedniej klasy. M.2 w zastosowaniach serwerowych jest wykorzystywane w sposób dwojaki:
pod system lub jako cache. NVMe jest realizowane innym formatem: U.2.
Świat poszedł do przodu i dziś SSD storage to U.2 i SAS 12G (i nadchodzący SAS 24G) . SATA się zwija. M.2 ma takie zastosowania, o których pisałem. Przewagą SATA jest odpowiednia jakość produktu tj. DWPD 3.
Dyski tależowe są do kitu. Nie dlatego, ze są totalnie złe, ale dlatego, że są za drogie w porównaniu do tego, co oferują (z wyjątkiem NLSAS).
Baza to jakieś 60GB, to same tabele, nie ma tam danych binarnych, czy przechowywania plików w tej bazie.
Jak się ma dysk SAS 15k 6Gbps do dysku M.2 z interfejsem 31.5 Gb/s? Wg strony https://en.wikipedia.org/wiki/IOPS SAS 15k ma powiedzmy 200 iops, a M.2 NVMe over PCIe 3.0 x4 mają po 200000-440000 tak że ze 2 TYSIĄCE razy lepiej… no sorry ale chyba ciężko będzie obronić tutaj dysk SAS 15k ale może spróbuj
Hotswap mi jest niepotrzebny. W obecnym serwerze mam, i nigdy nie użyłem. Gdy musiałem wymienić dysk, zatrzymałem serwer, zrobiłem image dysku i dopiero wymieniłem. Co do DWPD to zależy od modelu. Faktycznie nie ma w czym wybierać, jeśli chodzi o wysokie DWPD w dyskach M.2 a przynajmniej w tych szybszych, to można taki dysk np wymienić za 2 lata i spokój. Patrzyłem, to są np gwarancje na zapis, i widzę powiedzmy 300TB. Przeliczyłem, wychodzi, że przy obecnym użyciu tyle zapiszę przez 7 lat… No więc, znajdzie się jakiś m.2 godny uwagi? chyba, że jakieś rzeczowe argumenty jednak za czymś innym… ale nie takie, które już były omawiane.
Dysk systemowy, to dysk systemowy, powodów rozdzielenia może być kilka:
- Dysk systemowy może się zapchać (temp, aktualizacje itp.);
- Gdy robisz kopię systemu operacyjnego, niekoniecznie chcesz mieć w kopii zapasowej systemu operacyjnego bazy danych, bo backupujesz je osobno i zapewne częściej, niż system.
- Osobny wolumen łatwiej rozszerzyć.
- Gdy walnie Ci któryś z wolumenów, tracisz wszystko.
Znam przypadki, gdzie pliki MDF i LDF leżą na zupełnie osobnych wolumenach, dla przykładu C - system, D - MDF, E - LDF. Pliki LDF potrafią pychnąć i potrafią zajmować więcej, niż baza. To spowoduje, że baza stanie, gdy LDF zapcha Ci dysk z bazami.
Owszem podnosi koszt, ale tu już trzeba sobie odpowiedzieć, co jest większym kosztem - koszt dysku czy mniejszy zysk z powodu problemów z wydajnością. Można kupić serwer za 200 tys. złotych i jeden powie, że za drogi, a innemu przyniesie 100-krotne zyski.