Zwirtualizowany SQL Server: dlaczego nie?
Dział IT, w którym pracuję, próbuje przenieść się na 100% zwirtualizowane serwery, z wszystkimi danymi przechowywanymi na SAN. Jeszcze tego nie zrobili, ale plan ostatecznie wymaga przeniesienia istniejących fizycznych maszyn SQL Server na serwery wirtualne.
Kilka miesięcy temu uczestniczyłem w wydarzeniu Heroes Happen Here, a w jednej z sesji SQL Server prelegent wspomniał przelotnie, że nie jest to dobry pomysł na systemy produkcyjne.
Więc szukam kilku rzeczy:
- jakie są konkretne powody, dla których to jest lub nie jest dobrym pomysłem? Potrzebuję referencji, albo nie odpowiadam. Mógłbym wymyślić niejasną odpowiedź "I / O bound" na własną rękę przez google. Sam mówca HHH pewnie nie przekona naszego działu IT do zmiany zdania. Czy ktoś może wskazać mi coś bardziej autorytatywnego? I mówiąc "bezpośrednio", mam na myśli coś bardziej konkretnego niż tylko niejasne książki online komentarz. Proszę zawęzić trochę.
14 answers
Mogę to powiedzieć z własnego doświadczenia, ponieważ właśnie mam do czynienia z tym problemem. Miejsce, w którym obecnie pracuję jako wykonawca posiada tego typu środowisko dla swoich systemów programistycznych SQL Server. Staram się opracować dość skromny System B. I. na tym środowisku i naprawdę zmaga się z problemami wydajności.
Błędy TLB i emulowane wejścia / wyjścia są bardzo wolne na naiwnej maszynie wirtualnej. Jeśli twój O / S ma wsparcie parawirtualizacji (które nadal nie jest dojrzała technologia w systemie Windows) używasz parawirtualizowanego wejścia / Wyjścia(zasadniczo sterownika urządzenia, który łączy się z API w maszynie wirtualnej). Najnowsze wersje Opteron mają wsparcie dla zagnieżdżonych tabel stron, co eliminuje potrzebę emulowania MMU w oprogramowaniu (co jest bardzo powolne).
Tak więc aplikacje, które działają na dużych zestawach danych i wykonują wiele procesów We / Wy, takich jak (powiedzmy) ETL, przechodzą przez piętę achillesową wirtualizacji. Jeśli masz coś takiego jak system hurtowni danych, który może być trudny pamięć lub Dysk We / Wy powinieneś rozważyć coś innego. Dla prostej aplikacji transakcyjnej są prawdopodobnie O. K.
Umieścić w perspektywie systemy, których używam działają na blades (serwer IBM) na SAN z 4x 2gbit F/C łącza. To SAN średniego zasięgu. VM ma 4GB PAMIĘCI RAM IIRC, a teraz dwa wirtualne Procesory. W najlepszym wydaniu (gdy SAN jest cichy) jest to wciąż tylko połowa prędkości mojego XW9300, który ma 5 dysków SCSI (system, tempdb, logs, data, data) na 1 magistrali U320 i 4GB PAMIĘCI RAM.
Twój przebieg może się różnić, ale zalecałbym korzystanie z systemów stacji roboczych, takich jak ten, który opisałem, do tworzenia czegokolwiek ciężkiego We/Wy, zamiast serwerów wirtualnych na SAN. O ile twoje wymagania dotyczące korzystania z zasobów nie wykraczają poza tego rodzaju zestaw (w takim przypadku i tak wykraczają poza serwer wirtualny), jest to znacznie lepsze rozwiązanie. Sprzęt nie jest tak drogi - na pewno dużo tańszy niż SAN, obudowa blade i licencje VMWare. SQL Server developer edition pochodzi z V. S. Pro i wyżej.
Ma to również tę zaletę, że twój zespół programistów jest zmuszony zająć się wdrożeniem od samego początku - musisz wymyślić architekturę, która jest łatwa do wdrożenia za pomocą jednego kliknięcia. To nie jest takie trudne, jak się wydaje. Redgate SQL Compare Pro jest twoim przyjacielem tutaj. Twoi Programiści uzyskują również podstawową wiedzę praktyczną z zakresu administrowania bazami danych.
Szybka wycieczka na stronę HP dała mi cenę katalogową około 4600 dolarów za XW8600 (ich obecny model oparty na xeon) z czterordzeniowym układem xeon, 4GB PAMIĘCI RAM oraz dyskami twardymi 1x146 i 4X73GB 15K SAS. Cena ulicy będzie prawdopodobnie nieco niższa. Porównaj to z ceną licencji SAN, blade chassis i VMware oraz kosztem kopii zapasowej dla tej konfiguracji. W celu tworzenia kopii zapasowych możesz udostępnić udział sieciowy z backupem, w którym ludzie mogą upuścić skompresowane pliki kopii zapasowych DB w razie potrzeby.
EDIT: ten dokument na stronie internetowej AMD omawia niektóre benchmarki na maszynie wirtualnej. Po testach z tyłu, duże obciążenia We / Wy i MMU naprawdę osłabiają wydajność maszyn wirtualnych. Ich benchmark (należy przyjąć z przymrużeniem oka, ponieważ jest to statystyka dostarczona przez dostawcę) sugeruje karę 3,5 x prędkości na benchmarkerze OLTP. Podczas gdy jest to dostarczane przez Sprzedawcę, należy pamiętać:
Testuje naiwną wirtualizację i porównuje go do parawirtualizowane rozwiązanie, nie Bare-Metal performance.
Benchmark OLTP będzie miał więcej Random-access I / O obciążenie pracą i wola spędzaj więcej czasu czekając na dysk poszukuje. Bardziej sekwencyjny dysk wzór dostępu (charakterystyczny dla zapytań hurtowni danych) będzie miał wyższa kara, a pamięć-ciężka operacji (np. SSAS jest biblijny wieprz pamięci), który ma duża liczba błędów TLB będzie również ponieść dodatkowe kary. To oznacza, że spowolnienie na tym rodzaj przetwarzania byłby prawdopodobnie bardziej wyraźny niż OLTP benchmark kara cytowana w whitepaper.
Co widzieliśmy tutaj, że błędy TLB i I/O są bardzo drogie na maszynie wirtualnej. Dobra architektura z parawirtualizowanymi sterownikami i wsparciem sprzętowym w MMU złagodzi niektóre lub wszystkie te problemy. Uważam jednak, że Windows Server 2003 w ogóle nie obsługuje parawirtualizacji i nie jestem pewien, jaki poziom wsparcia jest dostarczany w Windows 2008 server. Z pewnością z mojego doświadczenia wynika, że maszyna wirtualna radykalnie spowolni serwer podczas pracy nad procesem ETL, a Cube buduje SSAS w porównaniu do stosunkowo skromnej specyfikacji sprzętu metalowego.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2008-12-11 17:19:21
SAN-oczywiście i klastrowanie, ale jeśli chodzi o wirtualizację - przyjmiesz Hit wydajności (może Ci się to opłacić, ale nie musi być tego warte):
Http://blogs.technet.com/andrew/archive/2008/05/07/virtualized-sql-server.aspx
Http://sswug.org miał kilka notek o tym w ich codziennym biuletynie ostatnio
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2008-09-29 15:58:31
Chciałem dodać tę serię artykułów Brenta Ozara:
- Dlaczego Twój Sysadmin chce wirtualizować Twoje serwery
- Po co wirtualizować SQL Server?
- powody, dla których nie powinieneś wirtualizować SQL Server
Nie jest to do końca autorytatywne w sensie, na jaki liczyłem (pochodzi od zespołu, który buduje serwer, lub jakiegoś oficjalnego podręcznika), ale Brent Ozar jest dość szanowany I myślę, że ma świetna robota.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2009-03-26 14:29:34
Uruchamiamy system płacowy dla ponad 900 osób na VMWare bez żadnych problemów. Ten był w produkcji przez 10 miesięcy. Jest to średnie obciążenie, jeśli chodzi o DB, a wstępnie przydzielono miejsce na dysku w maszynie wirtualnej, aby zapobiec problemom z IO. Musisz regularnie defragmentować zarówno Host maszyny wirtualnej, jak i plasterek maszyny Wirtualnej, aby utrzymać akceptowalną wydajność.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2008-09-29 21:36:59
Oto kilka testów VMWARE na nim.. http://www.vmware.com/files/pdf/SQLServerWorkloads.pdf
Oczywiście, nie porównują go do maszyn fizycznych. Ale prawdopodobnie możesz zrobić podobne testy z narzędziami, których używali w Twoim środowisku.
Aktualnie uruchamiamy SQL Server 2005 w środowisku VMWARE. Ale jest to bardzo lekko załadowana baza danych i jest świetna. Działa bez problemów.
Jak większość zauważyła, będzie to zależało od twojej bazy danych ładuj.
Może uda Ci się przekonać dział IT do zrobienia dobrych testów przed ślepym wdrożeniem.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2008-09-29 16:00:56
Nie, Nie mogę wskazać żadnych konkretnych testów, czy czegoś takiego, ale mogę powiedzieć z doświadczenia, że umieszczenie produkcyjnego serwera bazy danych na maszynie wirtualnej jest złym pomysłem, zwłaszcza jeśli ma duże obciążenie.
To jest dobre dla rozwoju. Być może nawet testowanie (przy teorii, że jeśli działa dobrze pod obciążeniem na wirtualnym pudełku, to będzie działać dobrze na produkcji), ale nie w produkcji.
To naprawdę zdrowy rozsądek. Czy chcesz, aby twój sprzęt działał na dwóch systemach operacyjnych i Twój serwer sql lub jeden system operacyjny i serwer sql?
Edytuj: Moje doświadczenie przesądziło o mojej odpowiedzi. Pracowałem z dużymi bazami danych pod dużym stałym obciążeniem. Jeśli masz mniejszą bazę danych przy niewielkim obciążeniu, wirtualizacja może działać poprawnie.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2008-09-29 16:02:17
Jest kilka informacji na ten temat w Conora Cunninghama artykuł na blogu Wirtualizacja baz danych-brudny mały sekret, o którym nikt nie mówi.... Cytat:
W samym serwerze jest zaskakująco mało wiedzy o wielu rzeczach w tej dziedzinie, które są ważne dla wydajności. Core engine SQL Server zakłada takie rzeczy jak:
- wszystkie procesory są równie wydajne
- wszystkie instrukcje procesowe procesora na około ta sama stawka.
- spłukanie dysku powinno nastąpić w ograniczonym czasie.
I post dalej omawia te kwestie również nieco dalej. Myślę, że dobra lektura, biorąc pod uwagę niedobór dostępnych informacji, biorąc pod uwagę ten problem w ogóle.
Uwaga istnieją specjalne produkty do wirtualizacji, które są tworzone dla baz danych, które mogą być warte zbadania zamiast ogólnego produktu, takiego jak VMWare.
Nasza firma (ponad 200 serwerów SQL) jest obecnie w trakcie wdrażania HP Polyserve na niektórych naszych serwerach:
Oprogramowanie HP PolyServe dla Microsoft SQL Server umożliwia konsolidację wielu instancji Microsoft SQL Server na znacznie mniejszej liczbie serwerów i scentralizowanym SAN magazyn. Unikalna architektura HP PolyServe "współdzielone DANE" zapewnia dostępność klasy korporacyjnej i elastyczność podobną do wirtualizacji w platformie narzędziowej.
Naszym głównym powodem wdrożenia jest ułatwienie wymiany sprzętu: dodaj nowe pole do "matrycy", przetasuj miejsce, w którym znajduje się każda instancja SQL (płynnie), a następnie usuń stare pole. Przezroczysty dla zespołów aplikacji, ponieważ nazwy instancji SQL nie zmieniają się.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2008-11-26 22:13:57
Stare pytanie ze starymi odpowiedziami
Odpowiedzi w tym wątku mają lat. Większość negatywnych punktów w tym całym wątku jest technicznie nadal poprawna, ale znacznie mniej istotna. Koszty ogólne wirtualizacji i SAN są teraz znacznie mniejsze niż kiedyś. Prawidłowo skonfigurowany host wirtualizacji, gość, Sieć i SAN może zapewnić dobrą wydajność dzięki zaletom wirtualizacji i elastyczności operacyjnej, w tym dobrym scenariuszom odzyskiwania które są dostarczane tylko przez bycie wirtualnym.
Jednak w prawdziwym świecie potrzeba tylko jednego drobnego szczegółu konfiguracji, aby rzucić wszystko na kolana. W praktyce twoim największym wyzwaniem z wirtualnymi serwerami SQL jest przekonanie i współpraca z osobami odpowiedzialnymi za wirtualizację, aby skonfigurować ją dokładnie.
Ironia, w 100 procentach przypadków, w których wycofaliśmy produkcję z wirtualizacji i przenieśliśmy ją z powrotem do dedykowanego sprzętu, przeszła przez dach na dedykowanym sprzęcie. We wszystkich tych przypadkach nie chodziło o wirtualizację, ale o sposób jej konfiguracji. Wracając do dedykowanego sprzętu udowodniliśmy, że wirtualizacja byłaby znacznie lepszym wykorzystaniem zasobów przez czynniki 5 lub więcej. Nowoczesne oprogramowanie jest zwykle zaprojektowane tak, aby skalować się między węzłami, więc wirtualizacja działa na Twoją korzyść również w tym zakresie.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2014-10-05 15:42:29
Największym problemem przy wirtualizacji oprogramowania jest zwykle licencjonowanie.
Oto artykuł na ten temat dla MS SQL. Nie jestem pewien swojej sytuacji, więc nie mogę wybrać żadnych istotnych punktów.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2008-09-29 15:55:16
SQL Server jest obsługiwany w środowisku wirtualnym. W rzeczywistości polecam zobaczyć, że jedna z opcji licencjonowania jest na gniazdo. Oznacza to, że możesz umieścić dowolną liczbę instancji SQL Server w zwirtualizowanym systemie (np.
Jest to lepsze niż to, ponieważ DataCenter jest licencjonowany na gniazdo z nieograniczoną licencją na maszyny wirtualne.
Polecam klastrowanie Twojego Hyper-V na dwóch maszyny jednak tak, że jeśli jeden zawiedzie drugi może podnieść Luz.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2008-09-29 15:56:05
Myślę, że możliwość, że coś złego dzieje się z danymi będzie zbyt wielka.
Jako martwy prosty przykład, załóżmy, że uruchomiłeś skrzynkę SQL Server w Virtual Server 2005 R2 i dyski cofania zostały włączone (więc główny plik "dysku" pozostaje taki sam, a wszystkie zmiany są dokonywane w oddzielnym pliku, który można później wyczyścić lub połączyć). Wtedy coś się dzieje (zazwyczaj trafiasz na limit 128GB czy jakakolwiek jest wielkość) i jakiś środek nocy bezmyślny admin musi się zrestartować i domyśla się, że nie może tego zrobić, dopóki nie usunie dysków cofania. Masz przerąbane - nawet jeśli przechowuje pliki na dysku cofania do późniejszej analizy, możliwości łączenia danych razem są dość wąskie.
Tak jak inne posty w tym wątku - na rozwój jest świetny, ale na produkcję to nie jest dobry pomysł. Twój kod można przebudować i ponownie wdrożyć (to inna sprawa, maszyny wirtualne do kontroli źródeł też nie są dobrym pomysłem), ale Twoje dane produkcyjne na żywo są o wiele ważniejsze.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2008-09-29 21:48:01
Należy również rozważyć kwestie bezpieczeństwa, które można wprowadzić w przypadku Witalizacji. Virtualization Security to dobry artykuł PandaLabs, który omawia niektóre problemy.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2009-01-16 16:39:16
Patrzysz na to z niewłaściwego kąta. Po pierwsze, nie znajdziesz białych dokumentów od dostawców, dlaczego powinieneś " Nie " wirtualizować lub dlaczego powinieneś wirtualizować.
Każde środowisko jest INNE i musisz robić to, co działa w Twoim środowisku. Mając to na uwadze, istnieją serwery, które są idealne do wirtualizacji i są takie, które nie powinny być zwirtualizowane. Na przykład, jeśli twój SQL Server / s wykonuje miliony i miliony transakcji na sekundę, na przykład jeśli Twój serwer znajdował się na NYSE lub NASDAQ i zależą od niego miliony dolarów, prawdopodobnie nie powinieneś go wirtualizować. Upewnij się, że rozumiesz konsekwencje wirtualizacji serwera SQL.
Widziałem, gdzie ludzie wirtualizują SQL w kółko tylko dlatego, że wirtualizacja jest fajna. Następnie narzekać później, gdy serwer VM nie działa zgodnie z oczekiwaniami.
To, co musisz zrobić, to ustawić benchmark, w pełni przetestować rozwiązanie, które chcesz wdrożyć i pokazać, co to Możesz, a nie możesz, więc nie napotkasz żadnych niespodzianek. Wirtualizacja jest świetna, jest dobra dla środowiska i oszczędza poprzez konsolidację, ale musisz pokazać, dlaczego twoi przełożeni nie powinni wirtualizować swoich serwerów SQL i tylko Ty możesz to zrobić.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2013-01-15 01:40:52