Jakie są wady uruchamiania bazy danych na maszynie wirtualnej? Jak je pokonać? [Zamknięte]

Bieganie nic wewnątrz maszyny wirtualnej będzie mieć pewien poziom przeboju wydajności, ale ile to naprawdę wpływa na wydajność systemu bazy danych?

Znalazłem ten akademicki dokument referencyjny z kilkoma interesującymi testami porównawczymi, ale był to ograniczony test z wykorzystaniem tylko Xen i PostgreSQL. Wniosek był taki, że użycie maszyny wirtualnej „nie wiąże się z wysokimi kosztami wydajności” (choć może się wydawać, że rzeczywiste dane mówią inaczej).

Jakie są techniczne, administracyjne i inne wady związane z uruchomieniem bazy danych na maszynie wirtualnej?

Proszę zamieścić odpowiedzi, które mogą być poparte obiektywnymi faktami, nie interesują mnie spekulacje ani żadne inne pół-religijne argumenty (pasja maniaków jest dobra na wiele sposobów, ale to nam nie pomoże).

Biorąc to pod uwagę,

• Jakie problemy pojawiają się podczas uruchamiania bazy danych na maszynie wirtualnej? (proszę zamieścić referencje)
• Czy te problemy są znaczące?
  • Czy mają one znaczenie tylko w niektórych scenariuszach?
• Jakie są obejścia?

Chociaż wielu dostawców DB bardzo powoli to robiło, prawie wszyscy oficjalnie obsługują teraz swoje oprogramowanie działające w środowisku zwirtualizowanym.

Obsługujemy wiele instancji Oracle 11g w systemie Linux na ESXi, i z pewnością można uzyskać bardzo dobrą wydajność. Podobnie jak w przypadku całego skalowania sprzętowego, musisz tylko upewnić się, że host wirtualizacji ma dużo zasobów (RAM, procesor) i że twoja warstwa dysku jest w stanie zapewnić wymaganą wydajność IO.

Jak mówi ErikA, staje się to coraz bardziej powszechne. Jestem w obozie SQL Server i osobiście nie mam żadnych systemów produkcyjnych działających na maszynach wirtualnych, ale nie zawahałbym się (po nieco więcej studiach na ten temat). Jednak zdecydowanie należy wziąć pod uwagę kilka rzeczy (przynajmniej w przypadku SQL Server). Disk IO (jak wspomnieli inni) i przydział pamięci to tylko 2 przykłady. Sprawy będą się również różnić między różnymi hiperwizorami.

Brent Ozar jest uznanym ekspertem w dziedzinie wirtualizacji SQL Server, szczególnie w VMWare. Gorąco polecam przeczytanie jego materiału.

http://www.brentozar.com/community/virtualization-best-practices/

Jest puszki i wtedy nie ma powinno . Korweta może jechać 150 mil na godzinę, ale czy powinieneś jeździć po drogach publicznych? Możesz niepotrzebnie zaszkodzić sobie.

Bazy danych to systemy operacyjne gościa. Z założenia, kiedy zaczynają, chwytają bloki zasobu i zarządzają nim bezpośrednio ze względu na wydajność. Gdy tylko uczynisz podstawowy system operacyjny serwera bazy danych gościem w zwirtualizowanym środowisku hostingowym, umieszczasz warstwę arbitrażową z hiperwizorem między elementem dysku i pamięci RAM przydzielonym do bloku a serwerem bazy danych. Spowolni. Im bardziej nieefektywne będą twoje zapytania, tym bardziej będzie wolniejsze. Te nieefektywności mogą być dziś maskowane na dedykowanym sprzęcie, ale jak tylko wprowadzisz arbitraż do swojego zasobu zależnego, szybko się dowiesz.

Wiele liczników fasoli wymagających wirtualizacji nie rozpoznaje tego, że serwery baz danych, jako systemy operacyjne gościa, oferują własną warstwę konsolidacji. Nie ma powodu, dla którego nie można przenieść konsolidacji wielu logicznych instancji bazy danych na jednym serwerze fizycznym, nawet do momentu przeniesienia adresów IP, skonfigurowania dodatkowych nazw hostów itp., Aby umożliwić to naturalne połączenie usług. A dzięki temu modelowi nie tylko oszczędzasz koszty, które kierownictwo naciska na zmniejszenie liczby fizycznych hostów, ale także blokujesz dostęp do zasobów fizycznych bez ingerencji arbitralnego hiperwizora, który może czasami podejmować korzystne decyzje, a nie inni

To samo dotyczy innych systemów operacyjnych gości, takich jak Java. Rozwiązania do wirtualizacji są zwykle środowiskami zajętymi i hiperwizor musi podejmować wiele decyzji dotyczących tego, kto „pobiera token” na zasobie. Za każdym razem, gdy możesz wyeliminować tę warstwę, będziesz lepiej.

Łączenie wielu instancji w pierwszej kolejności przy użyciu warstwy naturalnego systemu operacyjnego gościa. Szanse na to, że łatwiej będzie Ci osiągnąć konsolidację platformy i cele w zakresie wydajności.

Są tu dwie rzeczy do zrealizowania:

• Jednostka wydajności DB na jednostkę sprzętu jest nieco niższa dla zwirtualizowanej bazy danych. Oznacza to, że musisz kupić trochę więcej sprzętu, aby uzyskać ten sam poziom wydajności.
• To nie znaczy, że ten sam poziom lub pożądany poziom wydajności jest nieosiągalny. Zyski można uzyskać z poprawy zarządzania i innych świadczeń (HA), jak często łatwiejszy sposób więcej niż zrównoważyć nieznacznie zwiększonych kosztów sprzętowych.

To powiedziawszy, tam gdzie pracuję, nasza instalacja Sql Server jest jednym z dwóch serwerów, których nie zamierzam wirtualizować w najbliższym czasie (drugi to podstawowy DC).

Uruchamianie programu SQL Server jest maszyną wirtualną będzie w porządku, pod warunkiem, że można zapewnić maszynie wirtualnej wystarczającą ilość zasobów do uruchomienia aplikacji. Jeśli w świecie fizycznym potrzebujesz 24 rdzeni i 256 gigabajtów pamięci RAM, musisz zapewnić 24 vCPU i 256 gigabajtów pamięci RAM w świecie wirtualnym.

Właśnie napisałem artykuł w zeszłym miesiącu w magazynie SQL Server na temat uruchamiania SQL Server w vSphere VMware.

Prowadzę dwie bazy danych, jedną PostgreSQL i drugą MySQL, w środowisku wirtualnym (Xen), w którym dom0 są bardzo dostępne. Systemy plików domU znajdują się na iSCSI SAN LUN, wykrojonej z woluminów logicznych LVM2. Baza danych MySQL jest przeznaczona wyłącznie dla kaktusów, dlatego też nie ma większego zastosowania i znajduje się również na jednostce LUN iSCSI.

Baza danych PostgreSQL jest bazą danych dla naszego środowiska pomostowego, a zatem widzi większe wykorzystanie niż baza danych MySQL. Z tego powodu baza danych znajduje się na lokalnym zestawie RAID10, a DRBD jest replikowane do drugiego węzła klastra. Jednak pod względem rzeczywistego obciążenia ta baza danych pomostowych wcale nie wykazuje bardzo dużego obciążenia. Co moim zdaniem sprawia, że ​​jest dobrym / doskonałym kandydatem do wirtualizacji.

Niektóre z korzyści dla naszej organizacji to zmniejszenie zużycia energii, oszczędność miejsca w szafie i mniejsze obciążenie administracyjne sprzętu.

Z drugiej strony, nasza główna produkcyjna baza danych nie wyobrażam sobie wirtualnego ....

Pracuję z serwerami MSSQL i MySQL na wielu serwerach. Kilka lat temu wahałem się rozpocząć konfigurację serwerów SQL na maszynach wirtualnych, ponieważ słyszałem o problemach z wydajnością uruchamiania serwera SQL na maszynie wirtualnej. Byłem jednak zaskoczony po skonfigurowaniu pierwszych kilku serwerów SQL i nie zauważyłem żadnych zmian w wydajności. Coraz więcej serwerów, na których pracuję, znajduje się na maszynie wirtualnej, a prawie wszyscy więksi klienci korporacyjni, dla których pracuję, mają wirtulizowane serwery SQL.

Tak, maszyna wirtualna powoduje pewne koszty ogólne, a jeśli zamierzasz hostować wiele maszyn wirtualnych na jednym urządzeniu, potrzebujesz ładnego, mocnego serwera. Typowym problemem związanym z zasobami, na który należy zwrócić uwagę, jest dodanie dodatkowych maszyn wirtualnych i zmniejszenie dostępnych zasobów. Powszechną praktyką jest planowanie pewnego wzrostu, ale jeśli kupiłeś serwer do obsługi 2 lub 3 maszyn wirtualnych, a teraz działa na nim 10 maszyn wirtualnych, prawdopodobnie zauważysz wzrost wydajności.

Skłamałbym, gdybym powiedział, że nigdy nie widziałem problemów z wydajnością działania serwera SQL na maszynie wirtualnej. Ale nauczyłem się, że jeśli widzisz słabą wydajność, prawdopodobnie coś jest nie tak z otoczeniem.