Jak skonfigurować macierz RAID dysków SSD na moim serwerze SQL?

14

Buduję SQL Server z 48 GB pamięci RAM, 1 procesorem i 8 dyskami SSD SATA III (6 GB / s) (128 GB Crucial m4) i kontrolerem LSI MegaRAID (SAS 9265-8i). Oczekuję, że typowe obciążenie pracą będzie w większości odczytane. Będą pewne okresy intensywniejszej aktywności zapisu (godzinne synchronizacje danych z zewnętrznymi dostawcami danych - nocne kopie zapasowe), ale podejrzewam, że typowy współczynnik odczytu / zapisu wynosi około 90% odczytów / 10% zapisów.

Opcja 1:
Dysk logiczny C: - RAID 1 (2 dyski fizyczne) -
Dysk logiczny OS D: - RAID 10 (6 dysków fizycznych) - Pliki DB / logs / tempdb / kopie zapasowe?

LUB

Opcja 2:
Dysk logiczny C: - RAID 1 (2 dyski fizyczne) -
Dysk logiczny OS D: - RAID 1 (2 dyski fizyczne) - Pliki Db
Dysk logiczny E: - RAID 1 (2 dyski fizyczne) - pliki dziennika / kopie zapasowe?
Dysk logiczny F: - RAID 1 (2 dyski fizyczne) - tempdb

LUB

Opcja 3:
Inne sugestie?

Myślę, że opcja 1 dałaby mi lepszą wydajność, ponieważ cała aktywność DB byłaby rozłożona na 3 dyskach (i dublowana na pozostałych 3 w macierzy), chociaż opcja 2 wydaje się naśladować konwencjonalną mądrość (która wydaje się dotyczyć bardziej mechanicznej dyski niż dyski SSD). Wygląda na to, że przepełnienie stosu zniknęło z opcją 1 .

Zgaduję, że z dyskami SSD wszystko jest w porządku, aby umieścić wszystko na jednym dysku logicznym, ponieważ Twój serwer jest prawdopodobnie bardziej obciążony procesorem niż we / wy?

Kolejne pytanie, jakie mam, to gdzie mam umieszczać nocne kopie zapasowe? Nie chcemy, aby kopie zapasowe spowalniały resztę serwera SQL, i sądzę, że pisanie kopii zapasowych w tej samej lokalizacji, w której znajdują się dzienniki, jest dobrą praktyką, ponieważ zachowanie odczytu / zapisu w obu przypadkach jest zapisem sekwencyjnym.

Robbie
źródło
Kiedyś wierzyłem, że dystrybucja logiczna jest korzystna, ale po kilku dość obszernych badaniach (Michael może nadal ją mieć), doszliśmy do wniosku, że logiczna dystrybucja @ poziom docelowy nie poprawiła wydajności. Więc jeśli mówiliśmy o dysku fizycznym (wirującym), a chciałeś 8 plików danych, aby skorzystać z powinowactwa rdzenia, nie miało znaczenia, czy były to 8 plików na jednym woluminie logicznym (na tym samym dysku fizycznym), czy wycinasz 8 partycji logicznych dla tych 8 plików (na tym samym dysku fizycznym). Myślę, że podobnie będzie z logicznym cięciem dysku SSD
Eric Higgins

Odpowiedzi:

9

Konwencjonalna wiedza na temat RAID nie stosuje się dobrze do dysków SSD. Naprawdę nie potrzebują rozbierania (RAID0). Są podatne na awarie zgodnie z projektem, ale RAID-1 zwykle nie jest właściwą odpowiedzią na SSD z dwóch powodów: a) jest marnotrawstwem, zmniejsza o połowę pojemność macierzy SSD (i drogie) oraz 2) charakterystyka awarii dysków SSD w kierunku obu dysków w lustrze, aby ulegały awariom w bardzo bliskich odstępach czasu (tj. skorelowane awarie), przez co cała tablica była bezużyteczna. Zobacz Różnicową macierz RAID: Nowe podejście do macierzy dyskowej SSD w celu uzyskania dłuższej dyskusji. Niektórzy zalecali używanie Raid-6 dla dysków SSD.

Ponadto konwencjonalna mądrość układu plików programu SQL Server nie dotyczy dysków SSD. Polecam obejrzeć SQL na dyskach SSD: Hot and Crazy Love i przejrzeć łącza do testów porównawczych w tej odpowiedzi .

Remus Rusanu
źródło
Dobrze, że z RAID 10 jestem prawdopodobnie bardziej podatny na skorelowane awarie. Dzięki za łącze różnicowego RAID.
Robbie
8

Standardowe podejście do oddzielania losowych wzorców operacji we / wy danych od sekwencji dzienników po prostu nie dotyczy dysków SSD, więc wybrałbym opcję 1 z zastrzeżeniami:

  • Kopie zapasowe MUSZĄ znajdować się na osobnej maszynie. Nie ma sensu tworzenie kopii zapasowych, do których nie można uzyskać dostępu w przypadku, gdy serwer pójdzie w dym.
  • Oddzielenie danych i napędów dziennika ma pewną wartość, tak że awaria tablicy danych umożliwi wykonanie kopii zapasowej dziennika.
  • Pamiętaj, że nie masz gorących zapasów.
  • Pamiętaj, że masz dyski na poziomie konsumenta. Nie zakładaj, że będą one tak niezawodne jak ekwiwalenty przedsiębiorstwa przy wielokrotności kosztu.
  • Obejrzyj zabawny i bardzo pouczający SQL na dyskach SSD: Hot and Crazy Love autorstwa Brenta Ozara.

Problem oddzielania dzienników od danych, w których używane są dyski SSD, jest raczej kwestią RPO (celu punktu odzyskiwania) dla systemu niż wydajności. Jeśli RPO jest zdefiniowany w minutach, przejdź do jednej współużytkowanej tablicy i rób kopie zapasowe dziennika co [RPO] minut. Jeśli RPO jest zdefiniowany w sekundach, przejdź do oddzielnych tablic.

Szczerze mówiąc, jeśli RPO byłaby ciasna, zatrzymałbym dyski SSD dla macierzy danych i użyłby pary lustrzanych drogich (niezawodnych) niezawodnych spinnerów do dziennika.

Mark Storey-Smith
źródło
Kopie zapasowe są również kopiowane na osobny komputer. Są one tworzone na komputerze lokalnym, dzięki czemu mogę używać porównywania SQL / porównywania danych i przywracania zmian w przypadku regresji / błędu użytkownika.
Robbie
Ponadto RPO jest definiowany w minutach (myślę, że nawet w 10 minutach byłby do przyjęcia, aby mój scenariusz był całkowicie szczery). Post „Hot & Crazy Love” każe mi myśleć o skorelowanych niepowodzeniach. Z mojego ograniczonego doświadczenia miałem więcej awarii płyty głównej i całkowitych awarii systemu (zasilacz / skok mocy spieka wszystko), a następnie awarii napędu, więc wciąż próbuję ustalić, jaki byłby najbardziej opłacalny poziom paranoi / zapobiegania.
Robbie,
1

Powinieneś przejść z opcją 2 w następujący sposób:

Logical Drive - RAID 1 (2 physical drives)
 1 partition C: OS
 2 partition D: backups / log files
Logical Drive E: - RAID 1 (2 physical drives) - DATA files
Logical Drive F: - RAID 1 (2 physical drives) - INDEX files
Logical Drive G: - RAID 1 (2 physical drives) - tempdb

Rozdzielając dane i indeksy w 2 różnych plikach danych, które są następnie przechowywane na 2 różnych fizycznych dyskach logicznych, można uzyskać ogromny wzrost dysku io po prostu dlatego, że podczas kwerendy jeden dysk obraca się dla danych tabeli, a drugi jednocześnie kręci się po indeksie.

Pozostaw tempdb również oddzielone od kopii zapasowych, ponieważ dzieje się tam również wiele rzeczy. Nie mieszaj kopii zapasowych z plikiem danych. nawet jeśli kopie zapasowe nie są wykonywane codziennie, kiedy się pojawią, mają ogromny wpływ na twoje IO. na podstawie Twojej działalności i wykorzystania bazy danych niektóre osoby lub Mnóstwo osób mogą narzekać podczas tworzenia kopii zapasowej.

Mam nadzieję że to pomoże

Nicolas de Fontenay
źródło
6
Nonsens. Są to dyski SSD, a nie dyski.
Mark Storey-Smith
nie bez sensu nawet z SDD osiągnięto w ten sposób szereg wydajności, choć nie tak bardzo.
Nicolas de Fontenay,
2
Nawet w przypadku spinnerów oddzielanie danych od indeksów nie ma żadnej wartości, dopóki nie grasz na terytorium SQLCAT. Przypadek oddzielania tempdb również nigdy nie jest wyraźny i bardzo rzadko stosuje się w przypadku tak małej liczby dysków.
Mark Storey-Smith