Standardowa praktyka polegająca na oddzielaniu plików dziennika i danych w celu oddzielania dysków z dala od systemu operacyjnego (tempdb, kopie zapasowe i plik wymiany również) Czy logika ta ma sens, gdy wszystkie dyski są oparte na sieci SAN, a jednostki LUNS nie są rzeźbione z określonych zestawów dysków lub raidów - są tylko częścią liczby x napędów w sieci SAN, a jednostka LUN to tylko przydział miejsca
Odpowiedzi:
Dzienniki i dyski danych mają różne wzorce dostępu do danych, które są ze sobą w konflikcie (przynajmniej teoretycznie), gdy współużytkują dysk.
Zapisuje dziennik
Dostęp do dziennika składa się z bardzo dużej liczby małych sekwencyjnych zapisów. W pewnym uproszczeniu dzienniki DB są buforami pierścieniowymi zawierającymi listę instrukcji zapisywania elementów danych w określonych lokalizacjach na dysku. Wzorzec dostępu składa się z dużej liczby małych sekwencyjnych zapisów, które należy zagwarantować do końca - dlatego są zapisywane na dysk.
Idealnie byłoby, gdyby logi były na cichym (tzn. Nie współużytkowanym z niczym innym) woluminie RAID-1 lub RAID-10. Logicznie można zobaczyć proces jako główny DBMS zapisujący wpisy dziennika i jeden lub więcej wątków czytnika dziennika, które zużywają dzienniki i zapisują zmiany na dyskach danych (w praktyce proces jest zoptymalizowany, aby zapisy danych były zapisywane natychmiast, jeśli to możliwe). Jeśli na dyskach dziennika występuje inny ruch, głowice są przenoszone przez te inne wejścia, a sekwencyjne zapisy dziennika stają się losowymi zapisami dziennika. Są one znacznie wolniejsze, więc zajęte dyski dziennika mogą utworzyć punkt aktywny, który działa jako wąskie gardło w całym systemie.
Zapisuje dane
(zaktualizowany) Zapis dziennika musi zostać zatwierdzony na dysk (określany jako nośnik stabilny), aby transakcja była ważna i mogła zostać zatwierdzona. Można to logicznie wyświetlić jako zapisywane wpisy dziennika, a następnie używane jako instrukcje do zapisywania stron danych na dysk w procesie asynchronicznym. W praktyce zapisy stron na dysku są w rzeczywistości przygotowywane i buforowane w momencie dokonywania zapisu w dzienniku, ale nie muszą być zapisywane natychmiast, aby transakcja została zatwierdzona. Bufory dyskowe są zapisywane na stabilnym nośniku (dysku) przez proces Lazy Writer (podziękowania dla Paula Randala za zwrócenie na to uwagi), który ten artykuł Technet omawia nieco bardziej szczegółowo.
Jest to bardzo losowy wzorzec dostępu, więc współdzielenie tych samych dysków fizycznych z logami może stworzyć sztuczne wąskie gardło w wydajności systemu. Wpisy w dzienniku muszą zostać zapisane, aby transakcja mogła zostać zatwierdzona, więc losowe próby spowolnienia tego procesu (losowe operacje we / wy są znacznie wolniejsze niż sekwencyjne operacje we / wy logu) zmienią dziennik z sekwencyjnego w urządzenie o dostępie swobodnym. Stwarza to poważne wąskie gardło wydajności w zajętym systemie i należy go unikać. To samo dotyczy udostępniania obszarów tymczasowych woluminom dziennika.
Rola buforowania
Kontrolery SAN mają zwykle duże pamięci podręczne RAM, które do pewnego stopnia mogą absorbować ruch dostępu losowego. Jednak ze względu na integralność transakcyjną pożądane jest, aby zagwarantować, że zapisy z dysku z DBMS zostaną zakończone. Gdy kontroler jest ustawiony na używanie buforowania z zapisem wstecznym, brudne bloki są buforowane, a wywołanie We / Wy jest zgłaszane hostowi jako zakończone.
Może to rozwiązać wiele problemów z rywalizacją, ponieważ pamięć podręczna może wchłonąć wiele operacji we / wy, które w przeciwnym razie trafiłyby na dysk fizyczny. Może także zoptymalizować odczyty i zapisy parzystości dla RAID-5, co zmniejsza wpływ na wydajność woluminów RAID-5.
Są to cechy, które kształtują szkołę myślenia „Niech SAN sobie z tym poradzi”, choć ten pogląd ma pewne ograniczenia:
Buforowanie z zapisem w dalszym ciągu ma tryby awarii, które mogą spowodować utratę danych, a kontroler wykonał fleksję do DBMS, mówiąc, że bloki zostały zapisane na dysk, w rzeczywistości tak nie jest. Z tego powodu możesz nie chcieć używać buforowania zwrotnego dla aplikacji transakcyjnej, w szczególności do przechowywania danych o znaczeniu krytycznym lub finansowych, w przypadku których problemy z integralnością danych mogą mieć poważne konsekwencje dla firmy.
SQL Server (w szczególności) używa operacji we / wy w trybie, w którym flaga (zwana FUA lub Forced Update Access) wymusza zapis fizyczny na dysku przed powrotem wywołania. Microsoft ma program certyfikacji, a wielu dostawców SAN produkuje sprzęt, który spełnia te wymagania (podsumowano tutaj wymagania ). W takim przypadku żadna ilość pamięci podręcznej nie zoptymalizuje zapisów na dysku, co oznacza, że ruch w dzienniku zostanie zablokowany, jeśli siedzi on na zajętym współużytkowanym woluminie.
Jeśli aplikacja generuje duży ruch na dysku, jej zestaw roboczy może przepełnić pamięć podręczną, co również spowoduje problemy z rywalizacją o zapis.
Jeśli sieć SAN jest współdzielona z innymi aplikacjami (szczególnie na tym samym woluminie dysku), ruch z innych aplikacji może generować wąskie gardła dziennika.
Niektóre aplikacje (np. Hurtownie danych) generują duże skoki obciążenia przejściowego, co czyni je dość antyspołecznymi w sieciach SAN.
Nawet w przypadku dużych sieci SAN oddzielne woluminy dzienników są nadal zalecane. Możesz nie martwić się układem w lekko używanej aplikacji. W naprawdę dużych aplikacjach możesz nawet skorzystać z wielu kontrolerów SAN. Oracle publikuje szereg analiz przypadków dotyczących układu hurtowni danych, w których niektóre większe konfiguracje obejmują wiele kontrolerów.
Odpowiedzialność za wydajność tam, gdzie należy
W przypadku dużych woluminów lub w których wydajność może stanowić problem, zespół SAN ponosi odpowiedzialność za wydajność aplikacji. Jeśli będą ignorować zalecenia dotyczące konfiguracji, upewnij się, że kierownictwo jest tego świadome, a odpowiedzialność za wydajność systemu spoczywa w odpowiednim miejscu. W szczególności ustal akceptowalne wytyczne dla kluczowych statystyk wydajności DB, takie jak oczekiwania we / wy lub oczekiwania na zatrzask strony lub akceptowalne SLA aplikacji we / wy.
Pamiętaj, że ponoszenie odpowiedzialności za wyniki podzielone na wiele zespołów stwarza zachętę do wskazywania palcem i przekazywania złotówki drugiej drużynie. Jest to znany anty-wzorzec zarządzania i formuła dla problemów, które przeciągają się przez miesiące lub lata, ale nigdy nie zostały rozwiązane. Idealnie byłoby, gdyby jeden architekt posiadał uprawnienia do określania zmian konfiguracji aplikacji, bazy danych i SAN.
Przeprowadź również testy porównawcze systemu pod obciążeniem. Jeśli możesz to zorganizować, serwery z drugiej ręki i tablice z bezpośrednim podłączeniem można kupić dość tanio w serwisie eBay. Jeśli skonfigurujesz takie pole z jedną lub dwiema macierzami dyskowymi, możesz fregować się z konfiguracją dysku fizycznego i mierzyć wpływ na wydajność.
Jako przykład dokonałem porównania między aplikacją działającą na dużej sieci SAN (IBM Shark) a dwudrożną skrzynką z bezpośrednim podłączeniem tablicy U320. W tym przypadku sprzęt wart 3 000 funtów zakupiony w serwisie eBay był dwa razy lepszy od wysokiej klasy sieci SAN o wartości 1 miliona funtów - na hoście z mniej więcej taką samą konfiguracją procesora i pamięci.
Na podstawie tego szczególnego incydentu można argumentować, że umieszczenie czegoś takiego w pobliżu jest bardzo dobrym sposobem na zachowanie uczciwości administratorów SAN.
Zakładam, że tag Equallogic i treść żądania oznaczają, że zastanawiasz się nad SAN Equallogic. Poniższe informacje dotyczą w szczególności Equallogic i nie dotyczą innych typów sieci SAN.
W przypadku macierzy Equallogic określonych dysków używanych dla woluminów nie można określić tak dokładnie, jak to możliwe, na przykład w przypadku macierzy EMC Clariion, więc podejście musi być nieco inne.
Architektura Equallogic jest bardzo zautomatyzowana i dynamiczna. Jego podstawowym składnikiem jest jednostka macierzy, a nie paczki RAID \ grupy w obrębie macierzy, jak widać w innych sieciach SAN. Każda macierz jest w pełni skonfigurowana dla RAID 5, 6, 10 lub 50, chociaż nie oznacza to, że istnieje tylko jedna grupa RAID na macierz, po prostu nigdy nie możesz decydować o nich ani wchodzić w interakcje z nimi na tym poziomie. Umieszczasz tablice w pulach pamięci, a następnie twoje pule należą do grupy pamięci. Grupa magazynów ma klaster \ wirtualny adres ip, którego używasz jako celu iSCSI Discovery dla wszystkich woluminów w tej grupie - oprogramowanie do zarządzania grupą EQL i stos MPIO hosta obsługują ponowne wybieranie poziomu ip potrzebne do faktycznego przekierowania do najbardziej odpowiedniego portu na poszczególne tablice przy żądaniu bloków danych, ale jest to coś, co masz niewielką lub żadną kontrolę.
Woluminy pamięci są przypisywane z całkowitej ilości wolnego miejsca w każdej puli. Wszystkie woluminy w puli są rozłożone na wszystkie tablice w tej puli (maksymalnie do 4 oddzielnych tablic), aby rozdzielić sieciowe IO na całkowitą liczbę interfejsów sieciowych (2-4 na macierz Eql w zależności od modelu) i IO na jak największej liczbie kontrolerów. Oprogramowanie do zarządzania Equallogic monitoruje wydajność woluminów / macierzy w czasie i dynamicznie optymalizuje dystrybucję bloków między macierzami. Ogólnie rzecz biorąc, chyba że wiesz, co robisz, powinieneś umieścić wszystkie tablice w jednej puli i pozwolić, aby to zrobiło, pamiętaj tylko o tym, aby skonfigurować dyski o dużej prędkości (SAS 10k \ 15k) z RAID 10, średnie z RAID 50 lub 5 w celu zapewnienia, że proces optymalizacji faktycznie wybierze prawdziwe dyski o wysokiej wydajności.
W przybliżeniu będziesz miał około 2500-5000 IOP na macierz PS w zależności od typu dysku i typu RAID. Jeśli podasz wystarczającą liczbę procesorów IOP, automatyczny proces zarządzania powinien ostatecznie zapewnić dobrą wydajność, nawet jeśli po prostu zrzucisz wszystkie woluminy do jednej puli.
Jeśli jednak chcesz zagwarantować, że Twoje dzienniki, bazy danych, sklepy tymczasowe, dyski systemu operacyjnego itp. Są rzeczywiście odizolowane od siebie, możesz zrobić kilka rzeczy. Po pierwsze, możesz zdefiniować preferencje RAID dla woluminu, który zagwarantuje, że określony wolumin będzie zawsze przechowywany tylko w tablicach tego typu RAID (jeśli są obecne w puli, do której należy wolumin). Po drugie, możesz zdefiniować wielopoziomowe pule pamięci, które zawierają tylko tablice, które zapewniają różne stopnie wydajności wymagane dla tej konkretnej warstwy, a następnie rozdzielają woluminy na odpowiednie pule. Ostrzeżenie zdrowotne, które towarzyszy temu podejściu, mówi, że generalnie będziesz potrzebować wielu tablic, aby faktycznie zapewnić lepszą ogólną wydajność - może to być dla Ciebie mniej ważne niż zagwarantowanie wydajności na krytycznych woluminach, jednak często jest to wciąż najlepsza wybór. Architektura referencyjna Dell dla Oracle DB korzysta z jednej puli z 2 macierzami RAID 10 dla danych, dysku do głosowania i OCR oraz osobnej puli z jedną macierzą RAID 5 dla obszaru odzyskiwania Flash.
Przez cały czas w Equallogic należy zadać sobie pytanie, czy decyzje dotyczące wymuszonego partycjonowania zapewnią lepszą agregację wydajności woluminów pod względem dostępnych interfejsów sieciowych, wrzecion dyskowych i kontrolerów. Jeśli nie potrafisz odpowiedzieć na to pytanie, wybierz minimalną liczbę pul i pozostaw to do opanowania szczegółów lub poproś specjalistę Equallogic o wykonanie prawdziwego projektu. Jeśli masz tylko jedną tablicę, nie możesz nic zrobić, aby oddzielić woluminy.
Przechowujemy nasze DB na pojedynczych skrzynkach SAN, ale z osobnymi jednostkami danych, dziennikami i kopiami zapasowymi LUN, każda na różnych grupach dysków, podzielonych według prędkości - z naszymi dziennikami na jednostkach LUN RAID 10 15Krpm, danymi na jednostkach LUN RAID 1 10 / 15krpm i kopiami zapasowymi na RAID 5 jednostek LUN o prędkości 7,2 km / min. Prezentujemy również dzienniki i dane za pośrednictwem różnych kontrolerów w tej samej sieci SAN.
Świetne pytanie!
Najpierw spójrz na debatę Brenta Ozara „Steel Cage BlogMatch” na ten temat.
W naszej firmie, w przypadku większości serwerów, umieszczamy Dane i Logi na tym samym dysku SAN i pozostawiamy to zespołowi SAN, aby upewnić się, że wszystko działa poprawnie.
Zaczynam myśleć, że nie jest to najlepsza strategia, szczególnie w przypadku serwerów o większej objętości. Podstawowym problemem jest to, że tak naprawdę nie mam sposobu, aby zweryfikować, czy zespół SAN naprawdę robi coś więcej niż łączenie wystarczającej ilości dysków dla potrzebnej przestrzeni. Nie uruchamiamy testów porównawczych IO z dyskami SAN z naszej strony ani niczego, zakładamy, że „wykonują swoją pracę” (dostosowując się do wydajności, a także przestrzeni), co jest prawdopodobnie nieco naiwne.
Inną moją myślą jest to, że rodzaj dostępu, którego potrzebują dane i logi, jest inny. Spróbuję znaleźć artykuł, który ostatnio czytałem, który mówił o tym, jak dwa różne typy napędów powinny być naprawdę zoptymalizowane na bardzo różne sposoby (myślę, że jeden potrzebował optymalizacji dla sekwencyjnych zapisów, drugi wymagał optymalizacji dla losowych odczytów, coś takiego .)
Krótko mówiąc, tak, utworzyłbyś osobne woluminy dla plików danych SQL Server, plików dziennika oraz danych i plików dziennika TempDB.
Ponieważ otagowałeś swoje pytanie za pomocą Equallogic, przed zaprojektowaniem rozwiązania zapoznaj się z bezpłatnym Przewodnikiem po architekturze Dell: Wdrażanie Microsoft® SQL Server® z macierzami pamięci masowej Dell ™ EqualLogic ™ PS5000 (wymagana rejestracja). Często okazuje się, że wskazówki dotyczące konkretnych konfiguracji mogą znacznie różnić się od ogólnych porad .
Zgadzam się z BradC (+1) pod względem wydajności. Ogólnie dobra sieć SAN miałaby więcej surowych operacji we / wy, niż można się spodziewać.
Nadal dobrym pomysłem jest oddzielenie kopii zapasowych od systemu na żywo (oczywiście wiem, ale gdybym miał 1 £ za każdym razem, gdy to widzę ...)
Zalecane jest także trzymanie tempdb z dala od plików dziennika. Namiot faceta SAN, który rzuca na ciebie oczami, gdy zaczynasz chcieć „różnych wiader” (termin techniczny) dla dzienników, danych i temp., Ale jeśli im powiesz, możesz więc zmierzyć różną ilość danych IO przechodzących do każdego obszaru i spraw, by pokazali Ci swoje fantazyjne wykresy wydajności!
Wystarczy podwójnie / podwójnie sprawdzić, czy facet SAN skonfigurował go właśnie dla Ciebie. Jeśli chcesz RAID 10, nalegaj na to (ja tak zrobiłem), mimo że ciągle powtarzali, że ich RAID 5 nie ma ograniczenia wydajności.
(W przypadku operacji „opartych na plikach” RAID 5 jest w porządku. W przypadku intensywnych zapisów, jak tylko wypełnisz bufor zapisu, wkręcasz!)
Pamiętaj także o mieszaniu terminów tutaj ..
Ogólnie i bardzo podstawowe:
Możesz mieć kilka woluminów w tej samej tablicy, o czym należy pamiętać, gdy wykonujesz wysokiej jakości optymalizacje omówione w tym wątku.
Kluczem jest to, o czym wspomniało kilka innych (nie zapomnij o tym), oddzielenie danych / dziennika / kopii zapasowej na różnych wrzecionach dysku, a nie tylko na osobnych woluminach.
Edycja: a Helvick powyżej udzielił -dużej odpowiedzi na temat Equallogic SAN!