Pliki SQL Server Lokalne, NAS lub SAN?

Muszę zainstalować nowy serwer z SQL Server 2008, co polecasz, jeden serwer z Raid 10 lub pliki na serwerze NAS?

Co z iSCSI powinienem go używać?

Co z SAN?

Serwer ma 4 GB pamięci RAM, a plik bazy danych ma około 2 GB.

Żeby się dziś przekonać, że serwer nie ma RAID, muszę wdrożyć jakąś strategię, więc jeśli coś się stanie, mogę zabezpieczyć moje pliki, więc co powinienem wybrać Pliki lokalne, NAS, SAN? Która opcja ma największą wydajność, a która jest bezpieczniejsza?

NAS

Zdecydowanie nie NAS dla SQL Server. SMB / CIFS nie ma wystarczającej obsługi blokowania plików do obsługi DBMS (przynajmniej nie kilka lat temu, około 2002-2003). Zauważ, że działa NFS i możesz to zrobić za pomocą Oracle na serwerze NFS. Jednak SQL Server na udziale CIFS nie jest niezawodny z powodu ograniczeń protokołu. Może nawet nie pozwolić na umieszczanie plików w udziałach zamontowanych w CIFS.

SAN

Jest to dobre dla aplikacji transakcyjnych, ponieważ pamięć podręczna kontrolerów RAID może wchłonąć dość duże zestawy robocze. Kontrolery SAN RAID zwykle obsługują więcej pamięci podręcznej niż kontrolery RAID oparte na hoście, szczególnie w zestawach high-end, w których kontroler RAID może być urządzeniem wieloprocesorowym równie potężnym jak serwer.

Sieci SAN z podwójnymi kontrolerami mają również architekturę bez pojedynczego punktu awarii i oferują wiele opcji szybkiego tworzenia kopii zapasowych. To sprawia, że ​​wygrywają z punktu widzenia zarządzania i niezawodności. Są one jednak drogie i ograniczone do przesyłania strumieniowego woluminów danych, chociaż jest mało prawdopodobne, aby ten drugi problem stanowił problem w systemie transakcyjnym.

W przypadku systemów operacyjnych sieci SAN są prawie zawsze najlepszym wyborem, jeśli są dostępne. Mogą być również współużytkowane przez wiele serwerów z systemami o niskim i średnim wolumenie. Są one jednak wyposażone w metkę z ceną, która znacznie ogranicza dolną granicę najmniejszego systemu, z którym można korzystać z tej technologii.

Bezpośrednie dołączanie

W niektórych przypadkach najlepsze jest przechowywanie bezpośredniego załącznika. Jedną z możliwości są aplikacje do przesyłania strumieniowego z ograniczeniem przepustowości, w których ograniczona liczba połączeń kanału światłowodowego ograniczy dostępną przepustowość do mniejszej niż jest to możliwe w przypadku wysokiej klasy kontrolera SAS. Prawdopodobnie są to jednak dość wyspecjalizowane aplikacje, takie jak bardzo duże hurtownie danych, w których architektura współdzielenia niczego może zapewnić najlepszą przepustowość.

W rzeczywistości bezpośrednie podłączanie pamięci masowej jest często lepsze niż SAN dla systemów hurtowni danych z wielu powodów:

• Hurtownie danych nakładają duże skokowe obciążenia przejściowe na podsystemy dyskowe. To sprawia, że ​​są dość antyspołeczne w sieciach SAN, ponieważ mogą wpływać na wydajność innych systemów w sieci SAN.

• Wspomniane wąskie gardło przesyłania strumieniowego.

• Pamięć z bezpośrednim podłączeniem jest znacznie tańsza niż pamięć SAN.

Innym rynkiem pamięci masowej z bezpośrednim podłączeniem jest sprzedaż na rynku, który nie zapłaci wystarczającej ilości pieniędzy za SAN. Dotyczy to często aplikacji sprzedawanych klientom SMB. W przypadku systemu sprzedaży lub systemu zarządzania praktyką, który będzie miał sześciu użytkowników, SAN jest prawdopodobnie przesadą. W takiej sytuacji mały autonomiczny serwer typu tower z niektórymi dyskami wewnętrznymi jest znacznie bardziej odpowiednim rozwiązaniem.

Lokalny lub SAN to jedyny sposób na utrzymanie wydajności. W niektórych przypadkach sieć SAN może być szybsza niż dysk lokalny ze względu na większą pamięć podręczną zapisu i konfigurację przepustowości dysku równoległego.

Unikaj wykonywania wysokowydajnych operacji we / wy na plikach w systemie Windows. Narzuty związane z protokołem powodują znaczne spowolnienie przepustowości. Na przykład lata temu mierzyłem, że przesyłanie dużych plików przez sieć WAN było ~ 50% szybsze przy użyciu FTP przez udziały Windows.

Nie używaj NAS.

Albo użyj lokalnego (OK na średnioterminowy z dobrym kontrolerem RAID), ale jeśli pozwala na to budżet, wybierz przyzwoitą sieć SAN. Przy odrobinie szczęścia możesz zacząć „udostępniać” SAN innym systemom i odzyskać znaczną część początkowych nakładów.

4 GB pamięci RAM jest odpowiednie dla większości systemów, o ile jest to dedykowany SQL Server (i zawsze powinno być). Jeśli jeszcze tego nie rozważałeś, użyj 64-bitowego systemu operacyjnego i serwera SQL, aby łatwo wrzucić więcej pamięci RAM bez marnowania rzeczy PAE / AWE.

Pomyśl także o wirtualizacji. Potrzebujesz serwera testowego? Serwer deweloperów? Przetestować instalację dodatku SP1? (Bezwstydny plus za wcześniejszy post: sql-server-in-vmware )

Przy wielkości bazy danych 2 Gb nie ma powodu, aby nawet rozważać SAN. NAS nie będzie działać, powinieneś pomyśleć o używaniu NAS do tworzenia kopii zapasowych, więc nie przechowujesz kopii zapasowych na tym samym komputerze co twoje dane, i łatwo jest tworzyć kopie z NAS do przechowywania poza siedzibą.

W przypadku małej bazy danych po prostu używaj dysków lokalnych w macierzy RAID 1 lub RAID 10. Jeśli baza danych mieści się w pamięci RAM, nie musisz się martwić wydajnością operacji wejścia / wyjścia. Użyj 64-bitowych okien i umieść tam 8 koncertów. To pozostawi wiele dla systemu operacyjnego i da ci przestrzeń do rozwoju.

Pracuję z systemami, które korzystają zarówno z lokalnego dysku RAID, jak i SAN z łączem światłowodowym. Wygląda na to, że SAN działa lepiej, nawet jeśli ta pierwsza jest nowszą i szybszą maszyną. Myślę, że znaczącym czynnikiem jest to, że lokalny układ dysków jest pojedynczym dyskiem, więc SQL współdzieli dyskowe operacje we / wy z systemem operacyjnym i plikiem wymiany. Prawdopodobnie ma to duży wpływ na opór.

Jak wspomniano w @spoulson, SAN może zapewnić znacznie lepszą wydajność dysku. Jest to nie tylko oddzielny dysk, ale prawdopodobnie działa na znacznie szybszym sprzęcie dyskowym.

W naszym przypadku korzystamy z sieci SAN, ponieważ zapewnia ona scentralizowany obszar przechowywania dla grup usług VERITAS SQL Server w trybie failover. Gdy komputer podstawowy zawiedzie, dyski Windows zamontowane w sieci SAN zostaną ponownie zamontowane na maszynie do tworzenia kopii zapasowych na gorąco, a serwer dość szybko wróci. Oczywiście wymaga to systemu podobnego do VERITAS do zarządzania grupami usług, który może być poza twoim zakresem.

Jedynym zastrzeżeniem, z którym się zmagaliśmy, jest to, że przydzielanie miejsca na dysku SAN jest obsługiwane zachowawczo. Ponieważ jest drogi, nie podają go kaprysowi. Korzystając z EMC SAN, którego używamy, nie można odzyskać przydzielonego miejsca bez zrzucenia całej jednostki LUN. Jeśli więc stwierdzimy, że przydzielone miejsce jest więcej niż potrzebujemy i chcemy wykorzystać część tego miejsca na inną jednostkę LUN, nie możemy po prostu zmniejszyć tej zbyt dużej. Musimy to upuścić i zmienić przypisanie. To nie działa tak dobrze w środowisku produkcyjnym.

Jak sugerują inni, unikaj NAS. Równie dobrze możesz umieścić swoje pliki danych na zewnętrznym dysku twardym USB.

W przypadku małej bazy danych o pojemności 2 GB sieć SAN byłaby nadmierna.

Ogólnie rzecz biorąc, nie chcesz, aby twoje dyski SQL były współużytkowane z innymi aplikacjami. Podobnie, im więcej wrzecion (dysków) można rozłożyć na swoich plikach, tym lepiej. Ponownie, z małą bazą danych, którą opisujesz, będziesz w stanie zmieścić wszystko, czego potrzebujesz w pamięci RAM, więc wydajność dysku będzie mniejsza.

To powiedziawszy, nie idź i stwórz jednego woluminu RAID-10 i umieść na nim WSZYSTKIE pliki bazy danych. Możesz zacząć od czegoś prostego, takiego jak: Dane - 2x 73GB 15K RPM, Logi RAID1 - 2x 73GB 15K RPM, Kopie zapasowe RAID1 - pojedynczy duży 7200 RPM lub para w RAID1

Jeśli masz budżet na aktualizację, dodaj kolejny oddzielny wolumin dla TempDB (jeśli wykonujesz złożone zapytania / raporty analityczne) lub podaj wolumin Log więcej dysków i skonfiguruj go jako RAID10, jeśli w systemie jest więcej transakcji z dużym wolumenem aktualizacji.

SAN prawdopodobnie kosztowałby 3-4x tyle, co pamięć podłączona bezpośrednio dla równoważnej liczby dysków. Sieci SAN zapewniają wiele zaawansowanych możliwości tworzenia kopii zapasowych / migawek, obsługi klastrów oraz migracji i rozbudowy jednostek LUN. Jeśli są one dla Ciebie ważne, może być warte dodatkowych kosztów.

Oświadczenie: Istnieje wiele poważnych problemów z przechowywaniem plików bazy danych SQL Server na serwerze NAS. Wszystkie pozostałe opcje są równe, dobrze jest wybrać opcję SAN. Szczegółowe omówienie odpowiednich zagadnień znajduje się w MS KB304261 . Jednak ten wątek stał się odpowiedzią na inne pytania dotyczące programu SQL Server w udziale sieciowym, wolę publikować odniesienia do stanu obsługi NAS w wersjach SQL Server.

Sporo osób eksperymentuje teraz z wykorzystaniem NAS z MS SQL.

Kiedyś było to domyślnie zabronione, jednak można znieść ograniczenie w MS SQL 2008 i MS SQL 2005. Od MS SQL 2008 R2 nie ma takiego ograniczenia.

W MS SQL 2005 i 2008 kluczem jest flaga śledzenia, która zabrania używania udziałów sieciowych. Można wydać

 DBCC TRACEON(1807, -1)
 CREATE DATABASE [test] ON  PRIMARY 
 ( NAME = N'test', FILENAME = N'\\storage\mssql_db\test.mdf' )

Więcej szczegółów w poście z września 2010 r. Na blogu MSDN Varun Dhawan.

Możliwe jest przynajmniej technicznie uruchomione SQL Server na NAS. Wybór zależy od wielu czynników i nietrudno wyobrazić sobie sytuację, w której miejsce na bazę danych jest łatwo dostępne na serwerze NAS.