Zagadnienia dotyczące projektowania programu SQL Server

Program System Center Operations Manager korzysta z programu Microsoft SQL Server, aby obsługiwać operacyjne bazy danych, magazyn danych i bazy danych inspekcji ACS. Te bazy danych są niezbędne i są tworzone podczas wdrażania pierwszego serwera zarządzania lub modułu zbierającego ACS w grupie zarządzania.

W środowisku laboratoryjnym lub w małym wdrożeniu programu Operations Manager program SQL Server można przenieść na pierwszy serwer zarządzania w grupie zarządzania.

W przypadku rozproszonego wdrożenia od średniej do dużej skali przedsiębiorstwa, instancja SQL Server powinna być umiejscowiona na dedykowanym serwerze samodzielnym lub w konfiguracji wysokiej dostępności SQL Server. W obu przypadkach program SQL Server musi już istnieć i jest dostępny przed rozpoczęciem instalacji pierwszego serwera zarządzania lub modułu zbierającego ACS.

Nie zalecamy używania baz danych programu Operations Manager z wystąpienia SQL, które ma inne bazy danych aplikacji, aby uniknąć potencjalnych problemów z operacjami wejścia/wyjścia i innymi ograniczeniami zasobów sprzętowych.

Ważne

Operations Manager nie obsługuje wystąpień SQL typu Platforma jako Usługa (PaaS), w tym produktów, takich jak Azure SQL Managed Instance lub Amazon Relational Database Service (AWS RDS). Użyj wystąpienia programu SQL Server zainstalowanego na maszynie z systemem Windows. Jedynym wyjątkiem jest Azure Monitor SCOM Managed Instance, które wykorzystuje zarządzane wystąpienie Azure SQL MI, którego nie można ponownie skonfigurować.

Wymagania dotyczące programu SQL Server

Następujące wersje programu SQL Server Enterprise i Standard Edition są obsługiwane w przypadku istniejącej instalacji programu System Center Operations Manager w celu hostowania serwera raportowania, operacyjnej, magazynu danych i bazy danych ACS:

• SQL Server 2022 z minimalną aktualizacją zbiorczą 11 (CU11) lub nowszą, dostępną tutaj
• SQL Server 2019 z co najmniej aktualizacją zbiorczą 8 (CU8) lub nowszą dostępne tutaj
• SQL Server 2017 z najnowszą dostępną aktualizacją, dostępna tutaj

Przed uaktualnieniem programu SQL Server zobacz informacje o uaktualnieniu dla programu SQL 2017+ i informacje o uaktualnieniu programu SQL 2019.

Sterowniki programu SQL Server

Sterowniki OLE DB i ODBC programu SQL Server muszą być zainstalowane na wszystkich serwerach zarządzania i serwerze konsoli sieci Web, ponieważ te składniki bezpośrednio interfejsu z bazami danych i te sterowniki zezwalają na dostęp na poziomie interfejsu API do bazy danych SQL.

Zaleca się korzystanie z szyfrowanego połączenia z programem SQL Server; w tym celu należy zainstalować najnowsze wersje sterowników SQL:

• Najnowsza wersja sterownika OLE DB firmy Microsoft.
• Najnowsza wersja sterownika ODBC firmy Microsoft.

Więcej informacji na temat konfigurowania szyfrowania połączeń SQL można znaleźć tutaj: Konfigurowanie aparatu bazy danych programu SQL Server pod kątem szyfrowania połączeń

Jeśli nie korzystasz z zaszyfrowanych połączeń SQL, użyj poprzednich wersji sterowników SQL, które nie wymuszają szyfrowania:

• Sterownik Microsoft ODBC w wersji 17.10.6.
• Sterownik Microsoft OLE DB w wersji 18.7.4.

Aktualizacje programu SQL Server

Każdy z następujących składników programu SQL Server obsługujących infrastrukturę programu Operations Manager musi być w tej samej wersji głównej programu SQL Server:

• Wystąpienia aparatu bazy danych SQL Server hostujące dowolne bazy danych Operations Manager, w tym:
  • Kierownik Operacyjny
  • OperationManagerDW
  • Bazy danych usług SSRS ReportServer i ReportServerTempDB
• Instancja SQL Server Reporting Services (SSRS).

Tryb uwierzytelniania programu SQL Server

Domyślnie program SQL działa w konfiguracji uwierzytelniania w trybie mieszanym. Jednak program Operations Manager używa uwierzytelniania systemu Windows tylko do komunikowania się z programem SQL Server. Jeśli ustawienie uwierzytelniania w trybie mieszanym SQL pozostanie na wartościach domyślnych, nadal będzie funkcjonować, jeśli żadne konto lokalne nie ma roli db_owner. Konta lokalne z rolą db_owner są znane z powodowania problemów z Operations Manager.

Zdecydowanie zaleca się usunięcie db_owner roli ze wszystkich kont lokalnych przed zainstalowaniem produktu i nie dodawać db_owner roli do żadnych kont lokalnych po instalacji.

Inne uwagi

Inne zagadnienia dotyczące sprzętu i oprogramowania mają zastosowanie w planowaniu projektu:

• Zaleca się używanie dysków SQL w formacie pliku NTFS.
• Musisz mieć co najmniej 1 GB wolnego miejsca na dysku dla operacyjnej bazy danych i bazy danych magazynu danych. Jest to wymuszane podczas tworzenia bazy danych. Należy pamiętać, że wykorzystanie dysku baz danych znacznie wzrośnie po skonfigurowaniu, więc należy upewnić się, że jest dostępna duża ilość wolnego miejsca na dysku powyżej tego podstawowego wymogu.
• Jest wymagany program .NET Framework 4.
• Program .NET Framework 4.8 jest obsługiwany w programie Operations Manager 2022.
• Serwer raportowania nie jest obsługiwany w systemie Windows Server Core.
• Ustawienie sortowania programu SQL Server musi być jednym z obsługiwanych typów, zgodnie z opisem w sekcji: ustawienie sortowania programu SQL Server.
• Wyszukiwanie pełnotekstowe SQL Server jest wymagane dla wszystkich wystąpień silnika bazy danych SQL Server obsługujących dowolne bazy danych Operations Manager.
• Opcje instalacji systemu Windows Server (Server Core, Server with Desktop Experience i Nano Server) obsługiwane przez składniki bazy danych programu Operations Manager są oparte na opcjach instalacji obsługiwanych przez program SQL Server.

Aby uzyskać więcej informacji, zobacz sekcję Wymagania sprzętowe i programowe w dokumentacji dotyczącej instalacji i planowania programu SQL Server tutaj: Planowanie instalacji programu SQL Server

Ustawienie sortowania programu SQL Server

Następujące sortowania programu SQL Server i systemu Windows są obsługiwane w programie System Center Operations Manager.

Uwaga

Aby uniknąć problemów ze zgodnością podczas porównywania lub kopiowania operacji, zalecamy użycie tego samego sortowania dla bazy danych SQL i Operations Manager.

Sortowanie programu SQL Server

• SQL_Latin1_General_CP1_CI_AS

Porządkowanie systemu Windows

• Latin1_General_100_CI_AS
• French_CI_AS
• French_100_CI_AS
• Cyrillic_General_CI_AS
• Chinese_PRC_CI_AS
• Chinese_Simplified_Pinyin_100_CI_AS
• Chińskie_Tradicionalne_Liczba_Kresek_100_CI_AS
• Japanese_CI_AS
• Japanese_XJIS_100_CI_AS
• Traditional_Spanish_CI_AS (Hiszpański_tradycyjny_CI_AS)
• Modern_Spanish_100_CI_AS
• Latin1_General_CI_AS
• Cyrillic_General_100_CI_AS
• Korean_100_CI_AS
• Czech_100_CI_AS
• Hungarian_100_CI_AS
• Polish_100_CI_AS
• Finnish_Swedish_100_CI_AS

Jeśli wystąpienie programu SQL Server nie jest skonfigurowane przy użyciu jednego z wcześniej wymienionych obsługiwanych sortowań, wykonanie nowej konfiguracji programu Operations Manager zakończy się niepowodzeniem. Jednak aktualizacja na miejscu zakończy się pomyślnie.

Konfiguracja zapory

Program Operations Manager zależy od programu SQL Server do hostowania baz danych i platformy raportowania w celu analizowania i prezentowania historycznych danych operacyjnych. Role serwera zarządzania, operacji i konsoli sieci Web muszą być w stanie pomyślnie komunikować się z programem SQL Server i ważne jest, aby zrozumieć ścieżkę komunikacji i porty w celu poprawnego skonfigurowania środowiska.

Jeśli projektuje wdrożenie rozproszone korzystające z zawsze włączonych grup dostępności SQL, istnieją dodatkowe ustawienia konfiguracji zapory, które należy uwzględnić w strategii zabezpieczeń zapory.

W poniższej tabeli przedstawiono porty zapory wymagane przez program SQL Server, aby serwery zarządzania komunikowały się z bazami danych:

Scenariusz	Port	Kierunek	Rola menedżera ds. operacji
Program SQL Server hostuje bazy danych programu Operations Manager	TCP 1433 *	Przychodzący	serwer zarządzania i konsola sieci Web (dla usługi Application Advisor i diagnostyki aplikacji)
Usługa SQL Server Browser	UDP 1434	Przychodzący	serwer zarządzania
Dedykowane połączenie administratora programu SQL Server	TCP 1434	Przychodzący	serwer zarządzania
Inne porty używane przez program SQL Server - Zdalne wywołania procedur Microsoft (MS RPC) — Instrumentacja zarządzania Windows (WMI) — Koordynator transakcji rozproszonych firmy Microsoft (MS DTC)	TCP 135	Przychodzący	serwer zarządzania
Always On Availability Group Listener programu SQL Server	Port skonfigurowany przez administratora	Przychodzący	serwer zarządzania
Sql Server Reporting Services hostujący serwer raportowania programu Operations Manager	TCP 80 (wartość domyślna)/443 (SSL)	Przychodzący	serwer zarządzania i konsola operacji

Uwaga

Protokół TCP 1433 jest portem standardowym dla domyślnego wystąpienia aparatu bazy danych. Gdy tworzysz nazwane wystąpienie na autonomicznym serwerze SQL Server lub wdrożono grupę dostępności SQL Always On, zdefiniowany jest niestandardowy port i powinien być udokumentowany jako odniesienie, aby można było prawidłowo skonfigurować zapory i wprowadzić te informacje podczas instalacji.

Aby uzyskać bardziej szczegółowe omówienie wymagań zapory dla programu SQL Server, zobacz Konfigurowanie zapory systemu Windows pod kątem zezwalania na dostęp do programu SQL Server.

Zagadnienia dotyczące pojemności i magazynu

Baza danych programu Operations Manager

Baza danych programu Operations Manager to baza danych programu SQL Server, która zawiera wszystkie dane wymagane przez program Operations Manager do codziennego monitorowania. Ustalanie rozmiaru i konfiguracja serwera bazy danych ma kluczowe znaczenie dla ogólnej wydajności grupy zarządzania. Najbardziej krytycznym zasobem używanym przez bazę danych programu Operations Manager jest podsystem magazynowania, ale procesor CPU i pamięć RAM są również istotne.

Czynniki wpływające na obciążenie bazy danych programu Operations Manager obejmują:

• Szybkość zbierania danych operacyjnych.
  • Na szybkość zbierania danych operacyjnych wpływa czynniki, takie jak liczba importowanych pakietów administracyjnych, liczba dodanych agentów i typ monitorowanego komputera. Na przykład agent monitorujący komputer stacjonarny o krytycznym znaczeniu dla działania firmy zbiera mniej danych w porównaniu z agentem monitorujący serwer z uruchomionym programem SQL Server z wieloma bazami danych.
• Częstotliwość zmian przestrzeni wystąpień.
  • Aktualizowanie istniejących danych w bazie danych programu Operations Manager jest intensywnie obciążane zasobami w porównaniu do zapisywania nowych danych operacyjnych. Ponadto w przypadku zmian w danych przestrzeni instancji serwery zarządzania muszą wysyłać więcej zapytań do bazy danych w celu obliczenia zmian w konfiguracji i grupach. Częstotliwość zmian przestrzeni instancji zwiększa się podczas importowania nowych pakietów zarządzania lub dodawania nowych agentów do grupy zarządzania.
• Liczba konsoli operacji i innych połączeń zestawu SDK uruchomionych jednocześnie wpływa również na obciążenie bazy danych.
  • Każda konsola Operacje odczytuje dane z bazy danych programu Operations Manager. Wykonywanie zapytań dotyczących tych danych zużywa potencjalnie dużą ilość zasobów wejścia/wyjścia pamięci masowej, czasu procesora i pamięci RAM. Konsole operacji, które wyświetlają duże ilości danych operacyjnych w widoku zdarzeń, widoku stanu, widoku alertów i widoku danych wydajności, zwykle powodują największe obciążenie bazy danych.

Baza danych programu Operations Manager stanowi pojedynczy punkt awarii dla grupy zarządzania, więc można ją uczynić wysoce dostępna, korzystając z obsługiwanych konfiguracji przełączania awaryjnego, takich jak grupy dostępności Always On programu SQL Server lub wystąpienia klastrów failover.

Bazy danych programu Operations Manager można skonfigurować i zaktualizować, korzystając z istniejącej konfiguracji SQL Always-On, bez potrzeby dodatkowych zmian konfiguracji.

Włączanie usługi SQL Broker w bazie danych programu Operations Manager

Program System Center Operations Manager zależy od usługi SQL Server Service Broker w celu zaimplementowania wszystkich operacji zadań. Jeśli usługa SQL Server Service Broker jest wyłączona, wszystkie operacje zadań zostaną naruszone. Wynikowe zachowanie może się różnić w zależności od zainicjowanego zadania. Dlatego ważne jest, aby sprawdzić stan usługi SQL Server Service Broker za każdym razem, gdy nieoczekiwane zachowanie jest obserwowane wokół zadania w programie System Center Operations Manager.

Aby włączyć usługę SQL Server Service Broker, wykonaj następujące kroki:

1. Uruchom następujące zapytanie SQL, aby sprawdzić, czy broker jest już włączony, co wskazuje wynik 1 (jeden) w is_broker_enabled polu:

   SELECT is_broker_enabled FROM sys.databases WHERE name='OperationsManager'
   

2. Jeśli wartość wyświetlana w is_broker_enabled polu to 0 (zero), uruchom następującą instrukcję SQL, aby włączyć brokera:

   ALTER DATABASE OperationsManager SET SINGLE_USER WITH ROLLBACK IMMEDIATE
   ALTER DATABASE OperationsManager SET ENABLE_BROKER
   ALTER DATABASE OperationsManager SET MULTI_USER
   

Baza danych magazynu danych programu Operations Manager

Uwaga

Magazyn danych programu Operations Manager jest również nazywany bazą danych "Magazyn danych raportowania" lub po prostu "Magazyn danych" w dokumentacji.

Program System Center — Operations Manager wstawia dane do magazynu danych niemal w czasie rzeczywistym. Ważne jest, aby ten serwer miał wystarczającą pojemność, która umożliwia zapisywanie wszystkich zbieranych danych w magazynie danych. Podobnie jak w przypadku bazy danych programu Operations Manager, najbardziej krytycznym zasobem w magazynie danych jest podsystem we/wy pamięci masowej. W większości systemów obciążenia magazynu danych są podobne do bazy danych programu Operations Manager, ale mogą się różnić. Ponadto obciążenie nakładane na magazyn danych przez raportowanie różni się od obciążenia bazy danych Operations Manager przez użytkowanie konsoli operacyjnej.

Czynniki wpływające na obciążenie magazynu danych obejmują:

• Szybkość zbierania danych operacyjnych.
  • Magazyn danych wykonuje obliczenia i przechowuje zagregowane dane wraz z ograniczoną ilością danych pierwotnych, aby umożliwić wydajniejsze raportowanie. W związku z tym koszt zbierania danych operacyjnych do magazynu danych jest nieco wyższy w porównaniu z bazą danych programu Operations Manager. Jednak ten koszt jest kompensowany przez obniżony koszt przetwarzania danych odnajdywania w magazynie danych w porównaniu z bazą danych programu Operations Manager.
• Liczba współbieżnych użytkowników raportowania lub zaplanowane generowanie raportów.
  • Każdy użytkownik raportowania może dodać znaczne obciążenie systemu, ponieważ raporty często podsumowują duże ilości danych. Ogólne potrzeby dotyczące pojemności mają wpływ na liczbę uruchamianych jednocześnie raportów i typ uruchamianych raportów. Raporty, które wysyłają zapytania o duże zakresy dat lub dużą liczbę obiektów, wymagają dodatkowych zasobów systemowych.

Na podstawie tych czynników istnieje kilka zalecanych rozwiązań, które należy wziąć pod uwagę podczas określania rozmiaru magazynu danych:

• Wybierz odpowiedni podsystem magazynowania.
  • Ponieważ magazyn danych jest integralną częścią ogólnego przepływu danych przez grupę zarządzania, wybór odpowiedniego podsystemu magazynowania dla magazynu danych jest ważny. Podobnie jak w przypadku bazy danych programu Operations Manager, macierz RAID 0 + 1 jest często najlepszym wyborem. Ogólnie rzecz biorąc, podsystem magazynowania dla magazynu danych powinien być podobny do podsystemu magazynowania dla bazy danych programu Operations Manager, a wskazówki dotyczące bazy danych programu Operations Manager mają również zastosowanie do magazynu danych.
• Rozważ odpowiednie umieszczenie dzienników danych w porównaniu z dziennikami transakcji.
  • Jeśli chodzi o bazę danych programu Operations Manager, oddzielenie danych SQL i dzienników transakcji jest często właściwym wyborem podczas skalowania w górę liczby agentów. Jeśli zarówno baza danych programu Operations Manager, jak i magazyn danych znajdują się na tym samym serwerze i chcesz oddzielić dzienniki danych i dzienników transakcji, należy umieścić dzienniki transakcji dla bazy danych programu Operations Manager na oddzielnym woluminie fizycznym i dyskowych wrzecionach z magazynu danych, aby uzyskać jakiekolwiek korzyści. Pliki danych bazy danych programu Operations Manager i magazynu danych mogą współdzielić ten sam wolumin fizyczny, o ile wolumin zapewnia odpowiednią pojemność, a wydajność we/wy dysku nie ma negatywnego wpływu na funkcje monitorowania i raportowania.
• Rozważ umieszczenie magazynu danych na osobnym serwerze z bazy danych programu Operations Manager.
  • Chociaż wdrożenia na mniejszą skalę mogą często konsolidować bazę danych programu Operations Manager i magazyn danych na tym samym serwerze, korzystne jest ich oddzielenie w miarę zwiększania się liczby agentów i ilości przychodzących danych operacyjnych. Gdy magazyn danych i serwer raportowania znajdują się na innym serwerze niż baza danych programu Operations Manager, wydajność raportowania jest lepsza.

Baza danych magazynu danych programu Operations Manager jest pojedynczym źródłem awarii dla grupy zarządzania, więc można ją uczynić wysoce dostępną przy użyciu obsługiwanych konfiguracji trybu failover, takich jak Grupy dostępności Always On SQL Server lub Instancje klastra awaryjnego.

Zawsze włączony program SQL Server

Grupy dostępności Always On programu SQL Server obsługują awaryjne środowiska dla określonego zestawu baz danych użytkowników (baz danych dostępności). Każdy zestaw baz danych dostępności jest hostowany na replice dostępności.

W programie System Center 2016 i nowszym — Operations Manager, preferowanym rozwiązaniem dla zapewnienia wysokiej dostępności baz danych jest SQL Always On zamiast klastrowania trybu failover. Wszystkie bazy danych z wyjątkiem instalacji usług Reporting Services w trybie natywnym, która używa dwóch baz danych do oddzielenia magazynu trwałego od wymagań magazynu tymczasowego, mogą być hostowane w zawsze włączonej grupie dostępności.

Aby skonfigurować grupę dostępności, należy wdrożyć klaster Windows Server Failover Clustering (WSFC) do hostowania repliki dostępności, i włączyć funkcję Always On w węzłach klastra. Następnie możesz dodać bazę danych programu SQL Server programu Operations Manager jako bazę danych dostępności.

• Dowiedz się więcej o wymaganiach wstępnych Always On.
• Dowiedz się więcej o konfigurowaniu WSFC dla grup dostępności Always On.
• Dowiedz się więcej o konfigurowaniu grupy dostępności.

Napiwek

Począwszy od wersji Operations Manager 2022, można skonfigurować i uaktualnić bazy danych programu Operations Manager przy użyciu istniejącej konfiguracji SQL Always On, bez konieczności wprowadzania zmian w konfiguracji.

Aby skonfigurować grupę dostępności, należy wdrożyć klaster Windows Server Failover Clustering (WSFC) do hostowania repliki dostępności, i włączyć funkcję Always On w węzłach klastra. Następnie możesz dodać bazę danych programu SQL Server programu Operations Manager jako bazę danych dostępności.

• Dowiedz się więcej o wymaganiach wstępnych Always On.
• Dowiedz się więcej o konfigurowaniu WSFC dla grup dostępności Always On.
• Dowiedz się więcej o konfigurowaniu grupy dostępności.

Uwaga

Po wdrożeniu programu Operations Manager w węzłach programu SQL Server uczestniczących w programie SQL Always On, aby włączyć ścisłe zabezpieczenia środowiska CLR, uruchom skrypt SQL w każdej bazie danych programu Operations Manager.

Ciąg z wieloma podsieciami

Operations Manager nie obsługuje słów kluczowych w ciągu połączenia (MultiSubnetFailover=True). Ponieważ grupa dostępności ma nazwę odbiornika (znaną jako nazwa sieci lub punkt dostępu klienta w Menedżerze klastra WSFC) w zależności od wielu adresów IP z różnych podsieci, takich jak podczas wdrażania w konfiguracji trybu failover między lokacjami, żądania połączenia klienta z serwerów zarządzania do odbiornika grupy dostępności osiągną limit czasu połączenia.

Zalecanym podejściem do obejścia tego ograniczenia w przypadku wdrożonych węzłów serwera grupy dostępności w środowisku z wieloma podsieciami jest:

1. Ustaw nazwę sieci odbiornika grupy dostępności, aby zarejestrować tylko jeden aktywny adres IP w systemie DNS.
2. Skonfiguruj klaster tak, aby używał niskiej wartości TTL dla zarejestrowanego rekordu DNS.

Te ustawienia umożliwiają szybsze odzyskiwanie i rozpoznawanie nazwy klastra przy użyciu nowego adresu IP podczas przechodzenia w tryb failover do węzła w innej podsieci.

Uruchom następujące polecenia programu PowerShell w dowolnym z węzłów SQL, aby zmodyfikować następujące ustawienia:

Import-Module FailoverClusters
Get-ClusterResource "Cluster Name"|Set-ClusterParameter RegisterAllProvidersIP 0
Get-ClusterResource "Cluster Name"|Set-ClusterParameter HostRecordTTL 300
Stop-ClusterResource "Cluster Name"
Start-ClusterResource "Cluster Name"
Start-ClusterGroup "Cluster Name"

Jeśli używasz funkcji Always On z nazwą odbiornika, należy również wprowadzić te zmiany konfiguracji na odbiorniku. Aby uzyskać więcej informacji na temat konfigurowania słuchacza grupy dostępności, zobacz dokumentację tutaj: Konfigurowanie słuchacza grupy dostępności - SQL Server Always On.

Następujące polecenia programu PowerShell można uruchamiać w węźle SQL, który obecnie hostuje odbiornik, aby zmodyfikować jego ustawienia:

Import-Module FailoverClusters
Get-ClusterResource <Listener Cluster Resource name> | Set-ClusterParameter RegisterAllProvidersIP 0
Get-ClusterResource <Listener Cluster Resource name> | Set-ClusterParameter HostRecordTTL 300
Stop-ClusterResource <Listener Cluster Resource name>
Start-ClusterResource <Listener Cluster Resource name>
Start-ClusterGroup <Listener Cluster Group name>

Gdy klasterowane lub zawsze włączone wystąpienie SQL jest używane do wysokiej dostępności, należy włączyć funkcję automatycznego odzyskiwania na serwerach zarządzania, aby uniknąć ponownego uruchomienia usługi dostępu do danych programu Operations Manager w dowolnym momencie przejścia w tryb failover między węzłami. Aby uzyskać informacje o konfiguracji, zobacz następujący artykuł z bazy wiedzy Usługa Zarządzania System Center przestaje odpowiadać po tym, jak instancja programu SQL Server przechodzi w tryb offline.

Optymalizowanie programu SQL Server

Środowiska pomocy technicznej wykazały, że problemy z wydajnością nie są zwykle spowodowane wysokim wykorzystaniem zasobów (czyli procesorem lub pamięcią) z samym programem SQL Server; problem jest bezpośrednio związany z konfiguracją podsystemu magazynowania. Wąskie gardła wydajności są często przypisywane nieprzestrzeganiu zaleceń dotyczących konfiguracji przydzielonej pamięci masowej dla instancji bazy danych SQL Server. Oto następujące przykłady:

• Niewystarczający przydział wrzecion dla jednostek LUN w celu spełnienia wymagań IO systemu Operations Manager.
• Hostowanie dzienników transakcji i plików bazy danych na tym samym woluminie. Te dwa zadania obciążeniowe mają różne charakterystyki operacji I/O i opóźnienia.
• Konfiguracja bazy danych TempDB jest niepoprawna w odniesieniu do umieszczania, określania rozmiaru itd.
• Niezgodność partycji dysku woluminów hostowania dzienników transakcji bazy danych, plików bazy danych i bazy danych TempDB.
• Pomijanie podstawowej konfiguracji programu SQL Server, takiej jak używanie funkcji AUTOGROW dla plików dziennika bazy danych i transakcji, ustawienie MAXDOP dla równoległości zapytań, tworzenie wielu plików danych bazy danych TempDB na rdzeń procesora CPU itd.

Konfiguracja magazynu jest jednym z krytycznych składników wdrożenia programu SQL Server dla programu Operations Manager. Serwery baz danych zwykle mają duże ograniczenia we/wy z powodu rygorystycznego działania odczytu i zapisu bazy danych oraz przetwarzania dziennika transakcji. Wzorzec zachowania we/wy programu Operations Manager zwykle wynosi 80% operacji zapisu i 20% odczytów. W rezultacie niewłaściwa konfiguracja podsystemów we/wy może prowadzić do niskiej wydajności i działania systemów programu SQL Server i staje się zauważalna w programie Operations Manager.

Ważne jest przetestowanie projektu SQL Server, przeprowadzając testy przepustowości podsystemu we/wy przed wdrożeniem SQL Server. Upewnij się, że te testy są w stanie spełnić wymagania dotyczące operacji wejścia/wyjścia przy dopuszczalnym opóźnieniu. Użyj narzędzia Diskspd, aby ocenić pojemność we/wy podsystemu magazynowania obsługującego program SQL Server. Poniższy artykuł na blogu, napisany przez członka zespołu File Server w grupie produktowej, zawiera szczegółowe wskazówki i zalecenia dotyczące przeprowadzania testów wydajnościowych przy użyciu tego narzędzia: DiskSpd, PowerShell i wydajność magazynowania: mierzenie liczby operacji we/wy na sekundę, przepustowości i opóźnienia dla dysków lokalnych i udziałów plików SMB.

Rozmiar jednostki alokacji NTFS

Wyrównanie woluminu, często określane jako wyrównanie sektora, należy wykonać w systemie plików (NTFS) za każdym razem, gdy wolumin jest tworzony na urządzeniu RAID. Niezastosowanie się do tego może prowadzić do znacznego obniżenia wydajności i jest najczęściej wynikiem niezgodności partycji z granicami jednostek struktury paskowej. Może to również prowadzić do niewyrównania pamięci podręcznej sprzętowej, co skutkuje nieefektywnym wykorzystaniem pamięci podręcznej tablicy.

Podczas formatowania partycji używanej dla plików danych programu SQL Server zaleca się użycie rozmiaru jednostki alokacji 64 KB (czyli 65 536 bajtów) dla danych, dzienników i bazy danych TempDB. Należy jednak pamiętać, że użycie rozmiarów jednostek alokacji większych niż 4 KB powoduje brak możliwości korzystania z kompresji NTFS na woluminie. Chociaż program SQL Server obsługuje dane w trybie tylko do odczytu na skompresowanych woluminach, nie jest to zalecane.

Rezerwuj pamięć

Uwaga

Wiele informacji w tej sekcji pochodzi z Jonathan Kehayias w swoim wpisie na blogu Ile pamięci rzeczywiście potrzebuje mój program SQL Server? (sqlskills.com).

Nie zawsze łatwo jest zidentyfikować odpowiednią ilość pamięci fizycznej i procesorów do przydzielenia dla programu SQL Server w obsłudze programu System Center Operations Manager (lub innych obciążeń poza tym produktem). Kalkulator ustalania rozmiaru dostarczony przez grupę produktów zawiera wskazówki na podstawie skali obciążenia, ale jego zalecenia są oparte na testach wykonywanych w środowisku laboratoryjnym, które mogą lub nie są zgodne z rzeczywistym obciążeniem i konfiguracją.

Program SQL Server umożliwia skonfigurowanie minimalnej i maksymalnej ilości pamięci , która będzie zarezerwowana i używana przez jego proces. Domyślnie program SQL Server może dynamicznie zmieniać wymagania dotyczące pamięci na podstawie dostępnych zasobów systemowych. Ustawieniem domyślnym dla minimalnej pamięci serwera jest 0, a ustawieniem domyślnym maksymalnej pamięci serwera jest 2147 483 647 MB.

Problemy związane z wydajnością i pamięcią mogą wystąpić, jeśli nie ustawisz odpowiedniej wartości maksymalnej pamięci serwera. Wiele czynników wpływa na ilość pamięci, którą należy przydzielić do programu SQL Server, aby zapewnić, że system operacyjny może obsługiwać inne procesy uruchomione w tym systemie, takie jak karta HBA, agenci zarządzania i skanowanie antywirusowe w czasie rzeczywistym. Jeśli nie ustawiono wystarczającej ilości pamięci, system operacyjny i program SQL będą wykorzystywać dysk do stronicowania. Może to spowodować zwiększenie operacji we/wy dysku, dalsze zmniejszenie wydajności i utworzenie efektu falowania, w którym staje się zauważalne w programie Operations Manager.

Zalecamy określenie co najmniej 4 GB pamięci RAM dla minimalnej pamięci serwera. Należy to zrobić dla każdego węzła SQL hostowania jednej z baz danych programu Operations Manager (operacyjnej, magazynu danych, usługi ACS).

W przypadku maksymalnej pamięci serwera zalecamy, aby początkowo zarezerwować sumę:

• 1 GB pamięci RAM dla systemu operacyjnego
• 1 GB pamięci RAM na co 4 GB zainstalowanej pamięci RAM (do 16 GB pamięci RAM)
• 1 GB pamięci RAM na każde zainstalowane 8 GB pamięci RAM, przy sumie powyżej 16 GB pamięci RAM.

Po ustawieniu tych wartości należy monitorować licznik Pamięci\Dostępne bajty MBytes w systemie Windows, aby określić, czy można zwiększyć ilość pamięci dostępnej dla programu SQL Server. System Windows sygnalizuje, że dostępna pamięć fizyczna jest niska, wynosi 96 MB, dlatego licznik idealnie nie powinien spaść poniżej około 200–300 MB, aby zapewnić bufor. W przypadku serwerów z 256 GB pamięci RAM lub nowszej upewnij się, że nie działa on mniej niż 1 GB.

Pamiętaj, że te obliczenia zakładają, że program SQL Server ma mieć możliwość używania całej dostępnej pamięci, chyba że zmodyfikujesz je tak, aby uwzględniały inne aplikacje. Należy rozważyć szczególne wymagania dotyczące pamięci dla systemu operacyjnego, innych aplikacji, stosu wątków SQL Server i innych alokatorów wielostronicowych. Typową formułą jest ((total system memory) – (memory for thread stack) – (OS memory requirements) – (memory for other applications) – (memory for multipage allocators)), gdzie pamięć dla stosu wątków = ((max worker threads) (stack size)). Rozmiar stosu to 512 KB dla systemów x86, 2 MB dla systemów x64 i 4 MB dla systemów IA64, a wartość maksymalnej liczby wątków roboczych można znaleźć w kolumnie max_worker_count widoku sys.dm_os_sys_info.

Te zagadnienia dotyczą również wymagań dotyczących pamięci programu SQL Server do uruchamiania na maszynie wirtualnej. Ponieważ program SQL Server jest przeznaczony do buforowania danych w puli i używa jak największej ilości pamięci, trudno jest określić idealną ilość potrzebnej pamięci RAM. W przypadku zmniejszenia ilości pamięci przydzielonej do wystąpienia programu SQL Server można dojść do momentu, w którym mniejsza ilość pamięci skutkuje zwiększonym dostępem operacji we/wy na dysku.

Aby skonfigurować pamięć programu SQL Server w środowisku, które zostało przekonfigurowane, zacznij od monitorowania środowiska i bieżących metryk wydajności, w tym Menadżera bufora SQL Server oczekiwanie na długość życia strony oraz odczyty strony na sekundę i wartości odczyty z dysku na sekundę fizycznego dysku. Jeśli środowisko ma nadmiar pamięci, przewidywana długość życia strony zwiększy się o jeden z każdą sekundą bez żadnego spadku obciążenia ze względu na buforowanie; wartość odczytów stron/s w Menedżerze buforów SQL Server będzie niska po zapełnieniu pamięci podręcznej; a odczyty dysku/s również pozostaną niskie.

Po zrozumieniu punktu odniesienia środowiska można zmniejszyć maksymalną pamięć serwera o 1 GB, a następnie zobaczyć, jak wpływa to na liczniki wydajności (po ustąpieniu początkowej pamięci podręcznej). Jeśli metryki pozostaną akceptowalne, zmniejsz o kolejne 1 GB, a następnie ponownie monitoruj, powtarzając je zgodnie z potrzebami, aż określisz idealną konfigurację.

Aby uzyskać więcej informacji, zobacz Opcje konfiguracji pamięci serwera.

Optymalizowanie bazy danych TempDB

Rozmiar i fizyczne rozmieszczenie bazy danych TempDB może mieć wpływ na wydajność programu Operations Manager. Na przykład, jeśli rozmiar zdefiniowany dla TempDB jest zbyt mały, część obciążenia przetwarzania systemu może zostać zużyta na automatyczne powiększanie TempDB do rozmiaru wymaganego do prawidłowego działania przy każdym ponownym uruchomieniu instancji SQL Server. Aby uzyskać optymalną wydajność bazy danych TempDB, zalecamy następującą konfigurację bazy danych TempDB w środowisku produkcyjnym:

• Ustaw model odzyskiwania bazy danych TempDB na SIMPLE.
  • Ten model automatycznie odzyskuje obszar dziennika, aby zachować małe wymagania dotyczące miejsca.
• Wstępnie przydziel miejsce dla wszystkich plików TempDB, ustawiając rozmiar pliku na wartość wystarczająco dużą, aby pomieścić typowe obciążenie w środowisku. Zapobiega to zbyt częstemu rozszerzaniu bazy danych TempDB, co może mieć wpływ na wydajność. Bazę danych TempDB można ustawić na automatyczne zwiększanie, ale należy jej użyć do zwiększenia miejsca na dysku w przypadku nieplanowanych wyjątków.
• Utwórz dowolną liczbę plików, aby zmaksymalizować przepustowość dysku.
  • Użycie wielu plików zmniejsza rywalizację o magazyn bazy danych TempDB i zapewnia lepszą skalowalność. Nie twórz jednak zbyt wielu plików, ponieważ może zmniejszyć wydajność i zwiększyć obciążenie związane z zarządzaniem.
  • Ogólnie rzecz biorąc, utwórz jeden plik danych dla każdego procesora logicznego na serwerze (uwzględniając dowolne ustawienia maski koligacji), a następnie dostosuj liczbę plików w górę lub w dół w razie potrzeby.
  • Ogólnie rzecz biorąc, jeśli liczba procesorów logicznych jest mniejsza lub równa 8, należy użyć tej samej liczby plików danych co procesory logiczne.
    • Jeśli liczba procesorów logicznych jest większa niż 8, użyj ośmiu plików danych, a następnie jeśli rywalizacja będzie kontynuowana, zwiększ liczbę plików danych o wielokrotność 4 (do liczby procesorów logicznych), aż rywalizacja zostanie zmniejszona do akceptowalnych poziomów lub wprowadź zmiany w obciążeniu/kodzie.
    • Jeśli rywalizacja nie zostanie zmniejszona, może być konieczne zwiększenie liczby plików danych.
• Ustaw każdy plik danych na taki sam rozmiar, co zapewnia optymalną wydajność wypełniania proporcjonalnego.
  • Równe ustalanie rozmiaru plików danych ma kluczowe znaczenie, ponieważ algorytm wypełniania proporcjonalnego jest oparty na rozmiarze plików. Jeśli pliki danych są tworzone z nierównymi rozmiarami, algorytm wypełniania proporcjonalnego próbuje częściej używać największego pliku do alokacji GAM zamiast rozkładać alokacje między wszystkie pliki, tym samym niwecząc cel tworzenia wielu plików danych.
• Umieść bazę danych TempDB w szybkim podsystemie we/wy przy użyciu dysków półprzewodnikowych, aby uzyskać najbardziej optymalną wydajność.
  • Użyj usuwania dysku, jeśli istnieje wiele bezpośrednio dołączonych dysków.
• Umieść bazę danych TempDB na dyskach, które różnią się od tych, które są używane przez bazy danych użytkowników.

Aby skonfigurować bazę danych TempDB, możesz uruchomić następujące zapytanie lub zmodyfikować jego właściwości w programie Management Studio.

USE [TempDB]
GO
DBCC SHRINKFILE (N'tempdev' , 8)
GO
USE [master]
GO
ALTER DATABASE [TempDB] MODIFY FILE ( NAME = N'tempdev', NEWNAME = N'TempDB', SIZE = 2097152KB , FILEGROWTH = 512MB )
GO
ALTER DATABASE [TempDB] ADD FILE ( NAME = N'TempDB2', FILENAME = N'C:\Program Files\Microsoft SQL Server\MSSQL11.MSSQLSERVER\MSSQL\DATA\TempDB2.mdf' , SIZE = 2097152KB , FILEGROWTH = 512MB )
GO

Uruchom zapytanie SELECT * from sys.sysprocesses T-SQL, aby wykryć rywalizację o alokację stron dla bazy danych TempDB. W danych wyjściowych tabeli systemowej zasób oczekiwania może być wyświetlany jako "2:1:1" (strona PFS) lub "2:1:3" (strona współdzielonej globalnej mapy alokacji). W zależności od stopnia rywalizacji to ustawienie może prowadzić do braku odpowiedzi programu SQL Server w krótkich okresach. Innym podejściem jest zbadanie dynamicznych widoków zarządzania [sys.dm_exec_request lub sys.dm_os_waiting_tasks]. Wyniki pokazują, że te żądania lub zadania oczekują na zasoby bazy danych TempDB i mają podobne wartości, jak wyróżnione wcześniej podczas wykonywania sys.sysprocesses zapytania.

Jeśli poprzednie zalecenia nie zmniejszają znacząco rywalizacji o alokację, a rywalizacja znajduje się na stronach SGAM, zaimplementuj flagę śledzenia w parametrach uruchamiania dla SQL Server , aby flaga śledzenia pozostała w mocy nawet po ponownym uruchomieniu programu SQL Server. W ramach tej flagi śledzenia program SQL Server przydziela pełne zakresy do każdego obiektu bazy danych, eliminując tym samym rywalizację na stronach SGAM.

Uwaga

Ta flaga śledzenia wpływa na każdą bazę danych w instancji programu SQL Server.

Maksymalny stopień równoległości

Napiwek

Aby uzyskać najnowsze najlepsze rozwiązania i zalecenia od zespołu programu SQL Server, zapoznaj się z dokumentacją tutaj: Ustaw maksymalny stopień równoległości w celu uzyskania optymalnej wydajności

Domyślna konfiguracja programu SQL Server dla małych i średnich wdrożeń programu Operations Manager jest odpowiednia dla większości potrzeb. Jednak gdy obciążenie grupy zarządzania jest skalowane w górę w kierunku scenariusza klasy korporacyjnej (zazwyczaj 2000+ systemów zarządzanych przez agentów i zaawansowanej konfiguracji monitorowania, która obejmuje monitorowanie na poziomie usług z zaawansowanymi transakcjami syntetycznymi, monitorowanie urządzeń sieciowych, międzyplatformowe itd.), konieczne jest zoptymalizowanie konfiguracji programu SQL Server opisanego w tej sekcji dokumentu. Jedną z opcji konfiguracji, które nie zostały omówione w poprzednich wskazówkach, jest MAXDOP.

Opcja konfiguracji max degree of parallelism (MAXDOP) programu Microsoft SQL Server kontroluje liczbę procesorów używanych do wykonywania zapytania w planie równoległym. Ta opcja określa zasoby obliczeniowe i wątkowe, które są używane dla operatorów planu zapytania, które wykonują pracę równolegle. W zależności od tego, czy program SQL Server jest skonfigurowany na komputerze z symetrycznym przetwarzaniem wieloprocesorowym (SMP), komputerze bezformowym dostępem do pamięci (NUMA) lub procesorami obsługującymi funkcję hyperthreading, należy odpowiednio skonfigurować maksymalny stopień równoległości.

Gdy program SQL Server działa na komputerze z więcej niż jednym mikroprocesorem lub procesorem CPU, wykrywa najlepszy stopień równoległości, czyli liczbę procesorów używanych do uruchamiania pojedynczej instrukcji dla każdego wykonania planu równoległego. Domyślnie jej wartość dla tej opcji to 0, co umożliwia programowi SQL Server określenie maksymalnego stopnia równoległości.

Procedury składowane i zapytania wstępnie zdefiniowane w programie Operations Manager w odniesieniu do bazy operacyjnej, hurtowni danych, a nawet bazy danych audytu nie obejmują opcji MAXDOP, ponieważ podczas instalacji nie ma możliwości dynamicznego zapytania o liczbę procesorów dostępnych dla systemu operacyjnego, ani nie próbuje na sztywno ustalić tej wartości, co mogłoby mieć negatywne konsekwencje podczas wykonywania zapytania.

Uwaga

Opcja konfiguracji maksymalnego stopnia równoległości nie ogranicza liczby procesorów używanych przez program SQL Server. Aby skonfigurować liczbę procesorów używanych przez program SQL Server, użyj opcji konfiguracji maski koligacji.

• W przypadku serwerów korzystających z więcej niż ośmiu procesorów należy użyć następującej konfiguracji: MAXDOP=8

• W przypadku serwerów korzystających z ośmiu lub mniej procesorów użyj następującej konfiguracji: MAXDOP=0 do N

  Napiwek

  W tej konfiguracji N reprezentuje liczbę procesorów.

• W przypadku serwerów, które mają skonfigurowaną NUMA, parametr MAXDOP nie powinien przekraczać liczby procesorów CPU przypisanych do każdego węzła NUMA.

• W przypadku serwerów z włączoną funkcją hyperthreading wartość MAXDOP nie powinna przekraczać liczby procesorów fizycznych.

• W przypadku serwerów ze skonfigurowaną architekturą NUMA i włączoną funkcją hyperthreading wartość MAXDOP nie powinna przekraczać liczby procesorów fizycznych na węzeł NUMA.

Liczbę równoległych procesów roboczych można monitorować, wykonując zapytanie select * from sys.dm_os_tasks.

W tym przykładzie konfiguracja sprzętowa serwera to HP Blade G6 z 24 rdzeniami i 196 GB pamięci RAM. Wystąpienie hostująca bazę danych programu Operations Manager miało ustawienie MAXMEM o rozmiarze 64 GB. Po wykonaniu sugerowanych optymalizacji w tej sekcji wydajność uległa poprawie. Jednak wąskie gardło równoległości zapytań nadal występowało. Po przetestowaniu różnych wartości znaleziono najbardziej optymalną wydajność, ustawiając parametr MAXDOP=4.

Początkowa zmiana rozmiaru bazy danych

Próba oszacowania przyszłego wzrostu baz danych programu Operations Manager, w szczególności operacyjnych i baz danych magazynu danych, w ciągu pierwszych kilku miesięcy po wdrożeniu nie jest prostym ćwiczeniem. Pomocnik ustalania rozmiaru programu Operations Manager jest rozsądny w szacowaniu potencjalnego wzrostu na podstawie formuły opracowanej przez grupę produktową w wyniku testów laboratoryjnych, jednak nie bierze pod uwagę kilku czynników, które mogą wpływać na wzrost na krótką metę w porównaniu z długoterminowym wzrostem.

Początkowy rozmiar bazy danych, zgodnie z sugestią pomocnika określania rozmiaru, powinien zostać przydzielony do przewidywanego rozmiaru w celu zmniejszenia fragmentacji i odpowiedniego obciążenia, które można określić w czasie instalacji dla baz danych operacyjnych i bazy danych magazynu danych. Jeśli podczas instalacji jest za mało miejsca do magazynowania, bazy danych można rozszerzyć później przy użyciu programu SQL Management Studio, a następnie ponownie zindeksować je, aby odpowiednio zdefragmentować i zoptymalizować. To zalecenie dotyczy również bazy danych ACS.

Proaktywne monitorowanie wzrostu operacyjnej bazy danych i bazy danych magazynu danych powinno być przeprowadzane w cyklu dziennym lub tygodniowym. Jest to konieczne, aby zidentyfikować nieoczekiwane i znaczące skoki wzrostu i rozpocząć rozwiązywanie problemów, aby określić przyczynę, czy to z powodu błędu w przepływie pracy pakietu zarządzania (czyli reguła odnajdywania, reguła wydajności lub zbierania zdarzeń, monitor lub reguła alertu), lub inny symptom związany z pakietem zarządzania, który nie został zidentyfikowany podczas fazy testowania i zapewnienia jakości w procesie zarządzania wydaniami.

Automatyczne zwiększanie bazy danych

Gdy rozmiar pliku zarezerwowanych baz danych stanie się pełny, program SQL Server może automatycznie zwiększyć rozmiar o wartość procentową lub o stałą kwotę. Ponadto można skonfigurować maksymalny rozmiar bazy danych, aby zapobiec zapełnianiu całego miejsca dostępnego na dysku. Domyślnie baza danych programu Operations Manager nie jest skonfigurowana z włączoną funkcją automatycznego zwiększania; tylko bazy danych magazynu danych i ACS mają włączoną tę funkcję.

Polegaj na funkcji automatycznego zwiększania tylko jako zabezpieczeniu przy nieoczekiwanym wzroście. Funkcja Autogrow wprowadza karę za wydajność, którą należy wziąć pod uwagę podczas pracy z wysoce transakcyjną bazą danych. Kary za wydajność obejmują:

• Jeśli nie zapewnisz odpowiedniego przyrostu wzrostu, może wystąpić fragmentacja pliku dziennika lub bazy danych.
• Jeśli uruchomisz transakcję, która wymaga więcej miejsca w dzienniku dziennika niż jest dostępna, a automatyczne zwiększanie jest włączone dla dziennika transakcji tej bazy danych, czas ukończenia transakcji będzie obejmował czas potrzebny dziennikowi transakcji na wzrost o skonfigurowaną ilość.
• Jeśli uruchomisz dużą transakcję, która wymaga zwiększenia dziennika, inne transakcje, które wymagają zapisu w dzienniku transakcji, również będą musiały poczekać na ukończenie operacji powiększania.

Jeśli opcje autogrow i autoshrink są łączone, może to powodować niepotrzebne obciążenie. Upewnij się, że progi wyzwalające operacje zwiększania i zmniejszania nie spowodują częstych zmian rozmiaru w górę i w dół. Na przykład można uruchomić transakcję, która powoduje wzrost dziennika transakcji o 100 MB do momentu zatwierdzenia; jakiś czas po tym uruchamia się mechanizm automatycznego zmniejszania, który zmniejsza dziennik transakcji o 100 MB. Następnie uruchomisz tę samą transakcję i spowoduje to ponowne zwiększenie dziennika transakcji o 100 MB. W tym przykładzie tworzysz niepotrzebne obciążenie i potencjalnie tworzysz fragmentację pliku dziennika, co może negatywnie wpłynąć na wydajność.

Dokładnie skonfiguruj te dwa ustawienia. Konkretna konfiguracja naprawdę zależy od twojego środowiska. Ogólnie zaleca się zwiększenie rozmiaru bazy danych o stałą ilość w celu zmniejszenia fragmentacji dysku. Zobacz na przykład poniższą ilustrację, na której baza danych jest skonfigurowana do zwiększenia o 1024 MB za każdym razem, gdy jest wymagane automatyczne zwiększanie.

Polityka przełączeń awaryjnych klastra

Klaster z przełączaniem awaryjnym Windows Server to platforma wysokiej dostępności, stale monitorująca połączenia sieciowe i kondycję węzłów w klastrze. Jeśli węzeł nie jest osiągalny za pośrednictwem sieci, akcja odzyskiwania jest podejmowana w celu odzyskania aplikacji i usług online w innym węźle w klastrze. Domyślne ustawienia gotowe do użycia są zoptymalizowane pod kątem niepowodzeń, w których występuje całkowita utrata serwera, która jest uznawana za "trudną" awarię. Byłyby to nieodwracalne scenariusze awarii, takie jak awaria sprzętu bez redundancji lub zasilania. W takich sytuacjach serwer został utracony, a celem klastrowania w trybie failover jest szybkie wykrycie tej utraty i przywrócenie działania na innym serwerze w klastrze. Aby osiągnąć to szybkie odzyskiwanie po twardych awariach, domyślne ustawienia monitorowania kondycji klastra są dość agresywne. Jednak są one w pełni konfigurowalne, aby umożliwić elastyczność w różnych scenariuszach.

Te ustawienia domyślne zapewniają najlepsze działanie dla większości klientów; jednak, ponieważ klastry rozciągają się z odległości kilku cali do potencjalnie kilku mil, klaster może stać się bardziej narażony na bardziej i potencjalnie zawodne komponenty sieciowe między węzłami. Innym czynnikiem jest to, że jakość serwerów komercyjnych stale rośnie, a wraz z nią poprawia się odporność dzięki zastosowaniu nadmiarowych komponentów (takich jak podwójne zasilacze, tworzenie zespołów kart interfejsu sieciowego oraz wielościeżkowe wejście/wyjście). W rezultacie liczba awarii sprzętowych bez redundancji może być dość rzadka. Ponieważ trudne awarie mogą być rzadsze, niektórzy klienci mogą chcieć dostroić klaster pod kątem przejściowych awarii, gdzie klaster jest bardziej odporny na krótkie awarie sieci między węzłami. Zwiększając domyślne progi błędów, można zmniejszyć wrażliwość na krótkie problemy z siecią, które trwają krótki okres czasu.

Ważne jest, aby zrozumieć, że nie ma tu właściwej odpowiedzi, a zoptymalizowane ustawienie może się różnić w zależności od konkretnych wymagań biznesowych i umów dotyczących poziomu usług.

Wirtualizacja programu SQL Server

Ze względów wydajności w środowiskach wirtualnych zaleca się przechowywanie operacyjnej bazy danych oraz bazy danych magazynu danych na magazynie bezpośrednio podłączonym, a nie na dysku wirtualnym. Możesz użyć narzędzia Operations Manager Sizing Helper, opublikowanego dla programu Operations Manager 2012, aby oszacować wymagane IOPS i przetestować dyski danych pod kątem obciążenia w celu weryfikacji. Wydajność pamięci masowej można przetestować za pomocą narzędzia DiskSpd. Zobacz również Obsługa wirtualizacji programu Operations Manager, aby uzyskać dodatkowe wskazówki dotyczące zwirtualizowanego środowiska programu Operations Manager.

Tryb Always On oraz model odzyskiwania

Chociaż nie jest to ściśle optymalizacja, ważną kwestią dotyczącą Grupy Dostępności Always On jest fakt, że zgodnie z założeniem ta funkcja wymaga ustawienia baz danych w trybie odzyskiwania "Pełny". Oznacza to, że dzienniki transakcji nigdy nie są odrzucane, dopóki nie zostanie wykonana pełna kopia zapasowa lub tylko dziennik transakcji. Z tego powodu strategia tworzenia kopii zapasowych nie jest opcjonalna, ale wymagana część projektu AlwaysOn dla baz danych programu Operations Manager. W przeciwnym razie zapełniają się dyski zawierające dzienniki transakcji.

Strategia tworzenia kopii zapasowych musi uwzględniać szczegóły środowiska. Typowy harmonogram tworzenia kopii zapasowych znajduje się w poniższej tabeli.

Typ kopii zapasowej	Zaplanuj
Tylko dziennik transakcji	Co godzinę
Pełny	Co tydzień, niedziela o godzinie 3:00

Optymalizowanie usług raportowania programu SQL Server

Instancja Reporting Services działa jako serwer proxy dostępu do danych w bazie danych hurtowni danych. Generuje i wyświetla raporty na podstawie szablonów przechowywanych wewnątrz pakietów administracyjnych.

Rola raportowania programu Operations Manager nie może być zainstalowana w sposób równoległy z poprzednią wersją roli Raportowanie i musi być zainstalowana tylko w trybie natywnym (tryb zintegrowany programu SharePoint nie jest obsługiwany).

W tle usług Reporting Services działa instancja SQL Server, która hostuje bazy danych ReportServer i ReportServerTempDB. Ogólne zalecenia dotyczące optymalizacji wydajności tego wystąpienia mają zastosowanie.

Uwaga

W usługach SQL Server Reporting Services (SSRS) 2017 w wersji 14.0.600.1274 i nowszych domyślne ustawienia zabezpieczeń nie zezwalają na przekazywanie rozszerzeń zasobów. Prowadzi to do wyjątków ResourceFileFormatNotAllowedException w programie Operations Manager podczas wdrażania składników raportowania.

Aby rozwiązać ten problem:

1. Otwórz program SQL Management Studio.
2. Połącz się z instancją usług Reporting Services.
3. Kliknij prawym przyciskiem myszy wystąpienie serwera w oknie Eksploratora obiektów.
4. Wybierz Właściwości.
5. Wybierz pozycję Zaawansowane na lewym pasku bocznym.
6. Dodaj *.* do listy AllowedResourceExtensionsForUpload.

Alternatywnie można dodać pełną listę rozszerzeń raportowania programu Operations Manager do listy dozwolonych w usługach SSRS. Lista została opisana w sekcji "Rozwiązanie 2" tutaj: nie można wdrożyć raportów programu Operations Manager

Następne kroki

Aby dowiedzieć się, jak skonfigurować hostowanie magazynu danych (raportowania) za zaporą, zobacz Connect the (Reporting) Data Warehouse Across a Firewall (Łączenie magazynu danych (raportowania) przez zaporę.