Nie zwracaj uwagi na SAN za kurtyną

Dawno, dawno temu budowałem własne serwery SQL i miałem kontrolę nad konfiguracją dysków, poziomami RAID itp. Tradycyjna rada dotycząca oddzielania danych, dzienników, tempdb, kopii zapasowych (w zależności od budżetu!) Zawsze była bardzo ważną częścią procesu projektowania serwera SQL.

Teraz dzięki sieci SAN na poziomie przedsiębiorstwa po prostu żądam określonej ilości miejsca na dysku dla nowego serwera SQL, podzielonej na dyski logiczne do przechowywania danych, kopii zapasowych i udostępniania plików. Z pewnością ułatwia mi to pracę, ale jest taka część mnie, która nie czuje się całkowicie komfortowo, że tak naprawdę nie mogę zajrzeć „za zasłonę”, aby zobaczyć, co się tam naprawdę dzieje.

Rozumiem, że zespół SAN nie konfiguruje różnych „typów” dysków inaczej (optymalizując dyski danych pod kątem losowego dostępu w porównaniu z dyskami logowymi do zapisu strumieniowego). Niektóre z nich mogą zależeć od samego produktu SAN (mamy HP XP12000 i HP XP24000), ale zapewniłem, że oprogramowanie HP wykonuje wszelkiego rodzaju konfigurację wydajności dynamicznej (szukając hotspotów we / wy i rekonfigurując na bieżąco, aby zoptymalizować te jednostki LUN), aby zespoły aplikacji i DBA nie musiały się martwić żadnymi z tych rzeczy. Coś o „rozkładaniu obciążenia wszystkich serwerów na ogromną liczbę wrzecion” lub coś w tym rodzaju.

Moje pytania / dyskusja:

1. Nie czyniąc wrogów w zespole SAN, jak mogę zapewnić siebie i twórców aplikacji, że nasze serwery SQL nie cierpią z powodu źle skonfigurowanej pamięci? Używasz tylko statystyk perfmon? Inne testy porównawcze, takie jak sqlio?

2. Jeśli załaduję test na te dyski SAN, czy to naprawdę da mi niezawodną, ​​powtarzalną miarę tego, co zobaczę, gdy uruchomimy? (zakładając, że oprogramowanie SAN może „dynamicznie konfigurować” inaczej w różnych momentach).

3. Czy intensywne operacje we / wy w jednej części sieci SAN (powiedzmy na serwerze Exchange) wpływają na moje serwery SQL? (zakładając, że nie dają dedykowanych dysków każdemu serwerowi, co powiedziano mi, że nie są)

4. Czy pomogłoby w tym żądanie rozdzielenia dysków logicznych dla różnych funkcji dysków logicznych (dane vs log vs tempdb)? Czy SAN zobaczyć różne aktywności na tych IO i optymalnie skonfigurować je inaczej?

5. W tej chwili jesteśmy trochę w kryzysie kosmicznym. Zespołom aplikacyjnym polecono przycinanie archiwów danych itp. Czy problemy związane z przestrzenią zmusiłyby zespół SAN do podjęcia różnych decyzji dotyczących konfiguracji pamięci wewnętrznej (poziomy RAID itp.), Które mogłyby wpłynąć na wydajność mojego serwera?

Dziękuję za twoje przemyślenia (podobny temat krótko omówiony w tym pytaniu SF )

Nie czyniąc wrogów w zespole SAN, jak mogę zapewnić siebie i twórców aplikacji, że nasze serwery SQL nie cierpią z powodu źle skonfigurowanej pamięci? Używasz tylko statystyk perfmon? Inne testy porównawcze, takie jak sqlio?

Krótko mówiąc, prawdopodobnie nie ma sposobu, aby być naprawdę pewnym. Powiedziałbym (jestem administratorem SAN), że jeśli twoje aplikacje działają zgodnie z Twoimi oczekiwaniami, nie martw się o to. Jeśli zaczniesz dostrzegać problemy z wydajnością, które Twoim zdaniem mogą być związane z wydajnością SAN / Disk IO, dobrze jest zapytać. Nie używam dużo pamięci masowej HP, jak ty, ale w świecie IBM / NetApp z doświadczenia mogę powiedzieć, że nie ma wielu opcji, które pozwoliłyby ci skonfigurować ją „źle”. Większość pamięci masowej dla przedsiębiorstw zajmuje obecnie dużo czasu na domysły związane z budowaniem macierzy rajdowych i naprawdę nie pozwala ci to zrobić źle. Jeśli nie mieszają prędkości dysków i pojemności w ramach tych samych grup rajdowych, w większości przypadków możesz być pewien, że twój dysk działa dobrze.

Jeśli załaduję test na te dyski SAN, czy to naprawdę da mi niezawodną, ​​powtarzalną miarę tego, co zobaczę, gdy uruchomimy? (zakładając, że oprogramowanie SAN może „dynamicznie konfigurować” inaczej w różnych momentach).

Testy obciążeniowe powinny być dość niezawodne. Należy pamiętać, że podczas ładowania testu jednego urządzenia, które znajduje się na wspólnej sieci SAN / Disk Array, na jego działanie mogą (i będą) wpływać inne systemy korzystające z tej samej pamięci.

Czy intensywne operacje we / wy w jednej części sieci SAN (powiedzmy na serwerze Exchange) wpływają na moje serwery SQL? (zakładając, że nie dają dedykowanych dysków każdemu serwerowi, co powiedziano mi, że nie są)

To może. Nie chodzi tylko o dyski lub o dyski, na których działają serwery. Wszystkie dane są podawane przez kontroler dysku, a następnie przełącznik SAN. Wydajność, którą zobaczysz, zależy w dużej mierze od sposobu podłączenia kontrolera dysku do odpowiednich półek dyskowych i odpowiedniej sieci SAN. Jeśli cała macierz połączy się z siecią szkieletową SAN na jednej nici światłowodu 4 Gb / s, to wyraźnie wpłynie to na wydajność. Jeśli macierz jest połączona między dwoma redundantnymi sieciami SAN, które są równoważone obciążeniem, za pomocą łączy trunkingowych, sama wymiana nie byłaby w stanie zassać zbyt dużej przepustowości. Inną rzeczą, którą należy wziąć pod uwagę, jest to, ile IO / s jest w stanie obsłużyć tablica. Dopóki tablica i sieć SAN, z którą jest połączona, są poprawnie skalowane,

Czy pomogłoby w tym żądanie rozdzielenia dysków logicznych dla różnych funkcji dysków logicznych (dane vs log vs tempdb)? Czy SAN widziałby na nich różne operacje IO i optymalnie skonfigurowałby je inaczej?

Jest to prawdopodobnie kwestia preferencji, a także w dużym stopniu zależy od konfiguracji administratorów magazynu. Mogą dać ci trzy jednostki LUN w tej samej tablicy lub woluminie, w którym to przypadku i tak wszystko jest takie samo. Jeśli dali ci poszczególne jednostki LUN na różnych tablicach, w różnych objętościach (fizycznie różne dyski), być może warto je rozdzielić.

W tej chwili jesteśmy trochę w kryzysie kosmicznym. Zespołom aplikacyjnym polecono przycinanie archiwów danych itp. Czy problemy związane z przestrzenią zmusiłyby zespół SAN do podjęcia różnych decyzji dotyczących konfiguracji pamięci wewnętrznej (poziomy RAID itp.), Które mogłyby wpłynąć na wydajność mojego serwera?

Nie sądzę, aby administrator magazynu zmienił poziom nalotu, aby zwolnić miejsce. Jeśli tak, to prawdopodobnie powinien zostać zwolniony. Kwestie związane z przestrzenią mogą prowadzić do różnych konfiguracji, ale zwykle nie wpływają na wydajność. Mogą po prostu bardziej się zorientować, ile miejsca ci dają. Mogą one włączać funkcje takie jak usuwanie duplikatów danych (jeśli tablica je obsługuje), które mogą ograniczać wydajność tablicy podczas działania procesu, ale nie przez całą dobę.

Zespół SAN powinien dysponować narzędziami, które pomogą Ci odkryć, czy Twoja aplikacja jest popularna. Oczywiście powinieneś również monitorować i mierzyć swoje cele.

Większość mojego doświadczenia dotyczy EMC, więc YMMV. Ale poniższe zasady powinny mieć zastosowanie do większości urządzeń SAN.

Do tablicy wchodzi tylko tyle portów. Czasami istnieje przełączenie SAN, pomiędzy którymi można zdefiniować strefy. To, że tablica jest zasadniczo dużą pulą pamięci, nie oznacza, że ​​nie powinieneś się martwić wydajnością operacji wejścia / wyjścia.

Więc jeśli uważasz, że masz problemy z IO, musisz zawęzić wąskie gardło. Jeśli znajduje się gdzieś pomiędzy kartą HBA a tablicą, możesz dowiedzieć się, czy karta HBA jest maksymalnie obciążona, czy też port SAN po stronie przełącznika / tablicy jest nadmiernie subskrybowany. Ponadto powinieneś mieć zespół SAN monitorujący wzorce dostępu do aplikacji, zarówno od zimnego startu, jak i od gorąca.

Oczywiście, podstawowa pamięć masowa robi różnicę, powiedzmy, że działa powolny duży RAID5 w porównaniu z szybkim RAID10, ponieważ w pewnym momencie będziesz musiał trafić na dysk, niezależnie od różnych poziomów pamięci podręcznej.

HTH. Możesz pingować mnie offline, jeśli masz konkretny problem, ponieważ może to zająć trochę czasu.

Nie czyniąc wrogów w zespole SAN, jak mogę zapewnić siebie i twórców aplikacji, że nasze serwery SQL nie cierpią z powodu źle skonfigurowanej pamięci? Używasz tylko statystyk perfmon? Inne testy porównawcze, takie jak sqlio?

Pierwszą rzeczą, którą musisz wiedzieć przed wykonaniem jakiegokolwiek testu porównawczego, jest to, na jaką tolerancję ma pracować twoje własne obciążenie. Więc sprawdź swoje własne rzeczy przed wypróbowaniem nowego systemu. W ten sposób, jeśli stwierdzisz, że przepychasz maksymalnie, powiedzmy, 56 MB / s podczas szczytowych obciążeń (kopie zapasowe?), Dowiadując się, że macierz dyskowa dołączona do sieci SAN „tylko” przesuwa 110 MB / s pod symulowanym obciążeniem szczytowym, możesz zapewniłem, że limitem nie będzie kanał we / wy.

Sprawdzając nową macierz dyskową, przeprowadziłem tego rodzaju testy wydajności. Nowa tablica używała napędów SATA zamiast napędów Fibre Channel (SCSI) i musiałam się upewnić, że będzie działać w naszym środowisku. Byłem głęboko wątpliwy. Ale po scharakteryzowaniu dowiedziałem się, że nowy system ma wystarczającą ilość narzutów we / wy pod szczytem, ​​aby nadążyć za zmierzonym pikiem na bardziej niezawodnych dyskach. To mnie zaskoczyło.

Jeśli załaduję test na te dyski SAN, czy to naprawdę da mi niezawodną, ​​powtarzalną miarę tego, co zobaczę, gdy uruchomimy? (zakładając, że oprogramowanie SAN może „dynamicznie konfigurować” inaczej w różnych momentach).

Ze względu na wspólny charakter macierzy dysków podłączonych do sieci SAN, wydajność jest zmienna w ciągu tygodnia. Jeśli wiesz już, kiedy jest szczytowe obciążenie we / wy, wykonaj serię testów obciążenia w porze dnia, kiedy jest szczytowe obciążenie we / wy. W ten sposób możesz lepiej scharakteryzować, jaki rodzaj obciążenia We / Wy jest dostępny w okresach, które najbardziej Cię interesują. Testy obciążenia w okresach poza szczytem dadzą Ci wyobrażenie o tym, jak będą wyglądać „szybkie” rzeczy, ale testy szczytowe daje ci prawdziwe sprawdzanie granic.

Czy intensywne operacje we / wy w jednej części sieci SAN (powiedzmy na serwerze Exchange) wpływają na moje serwery SQL? (zakładając, że nie dają dedykowanych dysków każdemu serwerowi, co powiedziano mi, że nie są)

Jeśli jednostki Exchange LUN współużytkują dyski z jednostkami SQL LUN, absolutnie będą. Używamy HP EVA, a nie XP, ale myślę, że używają tej samej terminologii „grupa dysków”. Jednostki LUN na tych samych dyskach współużytkują dyski, dlatego walczą o wejścia / wyjścia na tych fizycznych urządzeniach. Im więcej dysków umieścisz w grupie dysków, tym więcej możliwości poruszania się w macierzy ma żonglowanie we / wy. Macierze (przynajmniej EVA to robią i zakładam, że droższe XP robią to samo) rozprowadzają logiczne bloki LUN na dyskach fizycznych w niesekwencyjny sposób. To pozwala mu robić to, co sugerujesz, czyli dynamicznie dystrybuować grupy często używanych bloków na różne urządzenia fizyczne, aby zwiększyć równoległość i zmniejszyć rywalizację we / wy na poziomie dysku.

Pytanie, które należy zadać, to ile budżetu we / wy ma ta grupa dysków i czy aplikacje korzystające z tych jednostek LUN mają nadmierną liczbę subskrypcji we / wy. Jest to pytanie, które administratorzy magazynu będą musieli śledzić. Może się zdarzyć, że szczytowe operacje we / wy dla programu Exchange (prawdopodobnie podczas tworzenia kopii zapasowych) mogą nie pokrywać się z obciążeniami SQL, a oba systemy mogą współistnieć z radością.

Czy pomogłoby w tym żądanie rozdzielenia dysków logicznych dla różnych funkcji dysków logicznych (dane vs log vs tempdb)? Czy SAN widziałby na nich różne operacje IO i optymalnie skonfigurowałby je inaczej?

W przypadku macierzy HP należy umieścić różne wzorce we / wy w różnych grupach dysków , a nie w jednostkach LUN. Wzory we / wy bazy danych nie powinny na przykład współistnieć z wzorcami dostępu do stron WWW. Różne jednostki LUN nie poprawiają znacząco wydajności, chyba że znajdują się w różnych grupach dysków. Jeśli należą do tej samej grupy dysków, jedyną prawdziwą zaletą jest system operacyjny, w którym może on planować operacje we / wy w jądrze, aby poprawić równoległość do podsystemu dyskowego. To mówi...

W moim przekonaniu macierze HP są świadome różnych wzorców dostępu w jednostkach LUN, ale zwracają szczególną uwagę na rzeczywiste logiczne bloki. Umieszczenie dzienników w innej jednostce LUN nakłada ograniczenia na bloki logiczne, które uzyskają tego rodzaju ruch we / wy i ułatwi zadanie prawidłowego sortowania bloków logicznych na dyskach fizycznych.

W tej chwili jesteśmy trochę w kryzysie kosmicznym. Zespołom aplikacyjnym polecono przycinanie archiwów danych itp. Czy problemy związane z przestrzenią zmusiłyby zespół SAN do podjęcia różnych decyzji dotyczących konfiguracji pamięci wewnętrznej (poziomy RAID itp.), Które mogłyby wpłynąć na wydajność mojego serwera?

Zdecydowanie. Jeśli brakuje miejsca, nie będziesz otrzymywać dedykowanych grup dysków dla swoich operacji we / wy (chyba że twoje środowisko pamięci masowej jest wystarczająco duże, aby uzasadnić przeznaczenie 7 TB dysku fizycznego na wyłączny użytek. W takim przypadku może tak być ). Debata Raid5 / Raid10 zależy w dużej mierze od polityk organizacji, a pytanie jest najlepszym wyborem.

Sugeruję otwarcie dialogu z zespołem SAN i dostawcą w celu rozwiązania problemów. Jednym z problemów, jakie wystąpią podczas prowadzenia własnych testów porównawczych, jest to, że testy mogą nie mieć wpływu na to, co dzieje się w produkcji, szczególnie przy szczytowych obciążeniach. Większość sieci SAN ma mnóstwo pamięci podręcznej z podtrzymaniem bateryjnym, co w wielu przypadkach (szczególnie podczas uruchamiania syntetycznych testów porównawczych) oznacza, że ​​piszesz do pamięci RAM i uzyskujesz niesamowitą wydajność.

W zależności od środowiska i używanego rozwiązania, niektórzy dostawcy CE mogli właśnie przylecieć i skonfigurować SAN zgodnie z preferowanym standardem. To się dzieje więcej niż myślisz. Będziesz musiał oderwać się od powłoki „zespół SAN wie wszystko”, dopóki nie będziesz mieć pewności, że rozwiązanie spełnia twoje wymagania.

Powodzenia.

Byłem kiedyś na konferencji Oracle z rozmową na ten temat - zdrowa sieć SAN dla baz danych.

Treść dyskusji jest dostępna w tym pliku PDF lub na stronie autorów tutaj