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

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.

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 są 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 .

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.

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