Szukam porady dotyczącej najlepszego sposobu konfiguracji moich dysków / partycji dla programu SQL Server. Oto niektóre z moich głównych obaw:
Jak należy rozdzielić pliki SQL (pliki danych, logi, temp)?
Czy lepiej jest RAIDować wiele dysków twardych i podzielić miejsce na partycje, czy też utworzyć wiele macierzy RAID z mniejszą liczbą dysków dla każdej macierzy RAID?
Czy dane i pliki dziennika powinny być innego typu RAID?
Czy domyślne bazy danych (master, msdb itp.) Powinny znajdować się na C: czy powinny znajdować się w tym samym miejscu, co inne pliki danych / dzienników?
sql-server
raid
partition
Sean Howat
źródło
źródło
To duże pytanie „to zależy”.
Nie mogę odpowiedzieć na pytanie, jak utworzyć dla ciebie pytanie dotyczące macierzy RAID, ponieważ nie jestem ekspertem od pamięci, ale mogę pomóc z resztą.
Pierwszą rzeczą, którą należy wziąć pod uwagę, jest obciążenie w różnych bazach danych - OLTP (odczyt / zapis) lub DSS / DW (głównie odczyt). W przypadku obciążeń odczytu / zapisu należy zwrócić uwagę na RAID 1 lub RAID 10 (RAID 1 + 0), ponieważ zapewniają one nadmiarowość i doskonałą wydajność odczytu / zapisu. W przypadku obciążeń głównie do odczytu można użyć RAID 5. Powodem, dla którego RAID 5 nie powinien być używany do obciążeń do odczytu / zapisu, jest obniżenie wydajności zapisu.
Dzienniki transakcji ze swej natury są do odczytu / zapisu (lub głównie do zapisu, w zależności od tego, czy używasz dziennika transakcji do czegokolwiek - np. Kopii zapasowych dziennika lub replikacji), dlatego nigdy nie powinno się go umieszczać na RAID 5.
Oznacza to, że w przypadku niektórych baz danych i obciążeń możesz mieć pliki danych na RAID 5 i pliki dziennika na RAID 1/10, a dla innych baz danych możesz mieć wszystko na RAID 1/10. Idąc dalej, jeśli masz partycjonowaną bazę danych, może ona zawierać głównie dane do odczytu i niektóre dane do odczytu / zapisu, być może nawet w tej samej tabeli. Można to podzielić na osobne aplikacjami, a następnie na każdej aplikacjach ustawić odpowiedni poziom RAID.
Oddzielenie rzeczywistych baz danych ponownie zależy od obciążenia pracą i możliwości bazowego podsystemu IO - na przykład może być wymagany wyższy stopień separacji do przechowywania rzeczy na poszczególnych macierzach RAID niż na SAN.
Tempdb jest specjalnym przypadkiem sam w sobie, ponieważ zwykle jest mocno obciążoną bazą danych i powinien być przechowywany oddzielnie od innych baz danych. Systemowe bazy danych nie powinny być intensywnie wykorzystywane i można je umieścić w dowolnym miejscu, o ile występuje nadmiarowość.
Oto link do białej księgi, którą pomogłem napisać, która powinna ci pomóc: Projekt fizycznego przechowywania danych . Upewnij się także, że podsystem IO może obsłużyć przewidywane obciążenie pracą - zobacz ten oficjalny dokument: Najlepsze praktyki we / wy przedwdrożeniowe . Na koniec upewnij się, że używasz prawidłowego rozmiaru paska RAID (zwykle 64 K lub więcej w nowszych systemach), prawidłowego rozmiaru jednostki alokacji NTFS (zwykle 64 K) oraz że w systemach wcześniejszych niż Windows Server 2008 poprawnie ustawiłeś przesunięcie partycji dysku . Aby uzyskać informacje na ich temat oraz wskazówki na ich temat i dlaczego należy je skonfigurować w ten sposób, zobacz ten wpis na blogu: Czy przesunięcia partycji dyskowych, rozmiary pasków RAID i jednostki alokacji NTFS są ustawione poprawnie? .
Linia Bototm: poznaj swoje obciążenie pracą i możliwości podsystemu IO, a następnie odpowiednio je zaimplementuj.
Mam nadzieję, że to ci pomoże.
PS Jeśli chodzi o tempdb, to jest duża paczka robaków na temat tego, jak powinieneś go skonfigurować i jest wiele różnych sprzecznych informacji. Napisałem obszerny post na blogu o konfiguracji pliku danych tempdb na błędnych przekonaniach dotyczących TF 1118 .
źródło
Krótka odpowiedź dla serwerów, które skonfigurowałem, zawsze była
Loguje się na osobnych dyskach fizycznych, raid 1 lub 10 (striping + mirroring)
Baza danych na własnych dyskach, w zależności od potrzeb wydajnościowych, zwykle RAID5
Dużo pamięci podręcznej na kontrolerach RAID
Najlepiej ponownie przyklej system operacyjny i plik stronicowania Windows do osobnej tablicy, zwykle tylko do kopii lustrzanej (Raid 1). Dzięki temu wszystkie operacje zapisu są rozdzielone, więc duża wydajność nie pociąga za sobą wszystkiego.
Doświadczyłem w przeszłości, że zapisywanie bazy danych + zapisywanie dziennika + zapisywanie pliku strony spowoduje utratę tablicy Raid5, a wydajność pójdzie do cholery w koszyku. Problem polega na tym, że Twoja wydajność będzie w porządku w testowaniu, tworzeniu itp. Ale kiedy wejdziesz w produkcję i użycie gwałtownie wzrosną, ten problem będzie wyglądał „na niebiesko”, a skargi użytkowników gwałtownie wzrosną.
źródło
Są tu o wiele lepsi faceci MSSQL niż ja, ale ogólnie sugeruję, co następuje;
System operacyjny i kod na C: - powinny to być dyski lokalne, powinna to być para macierzy RAID1 - do tego używamy 2 x 2,5-calowych dysków SAS 146 GB 10krpm, ale możesz użyć 2 dysków SATA 7.2. Dane powinny znajdować się na dość szybkiej macierzy RAID 1/10, 5/50/6/60 o dowolnej wielkości - macierz RAID 1/10, 5/50/6/60 - trzymamy nasze na jednostkach FC SAN LUN, zwykle na grupie dysków „poziomu 2” / 10krpm . Dzienniki powinny znajdować się na osobnej bardzo BARDZO SZYBKO (15krpm) małej (10 GB lub mniejszej?) Parze macierzy RAID 1 - trzymamy nasze na FC SAN LUN, zwykle na bardzo małej grupie dysków „poziom 1” / 15krpm lub na „poziom 0” / grupa ssd.
Tak czy inaczej, chcesz, aby każda porcja na oddzielnych wrzecionach / macierzach była wydajna - oczywiście wszystko będzie działać na jednym dysku, ale myślę, że szukasz równowagi między wydajnością a kosztami.
Przechowujemy nasz master / tempdb w naszych regularnych bazach danych, ale możesz podzielić go na oddzielną tablicę danych LUN.
Mam nadzieję że to pomoże.
źródło