Udostępnij za pośrednictwem

Zagadnienia dotyczące projektowania programu SQL Server

  • Artykuł

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 wdrożenia rozproszonego o średniej skali przedsiębiorstwa wystąpienie programu SQL Server powinno znajdować się na dedykowanym serwerze autonomicznym lub w konfiguracji wysokiej dostępności programu 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 we/wy i innymi ograniczeniami zasobów sprzętowych.

Ważne

Program 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 wystąpienie zarządzane SCOM usługi Azure Monitor, które korzysta z wystąpienia zarządzanego usługi Azure SQL, i nie można go 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 2019 z minimalną aktualizacją zbiorczą 8 (CU8) lub nowszą, jak jest dostępna tutaj
  • SQL Server 2016 i najnowsze aktualizacje dostępne tutaj
  • SQL Server 2022 z minimalną aktualizacją zbiorczą 11 (CU11) lub nowszą, jak jest dostępna tutaj
  • SQL Server 2019 z minimalną aktualizacją zbiorczą 8 (CU8) lub nowszą, jak jest dostępna tutaj
  • PROGRAM SQL Server 2017 z najnowszą dostępną aktualizacją, jak jest dostępny tutaj
  • Aktualizacje zbiorcze i sql Server 2017, jak opisano tutaj
  • Sql Server 2016 i Dodatki Service Pack, jak opisano tutaj

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

  • SQL Server 2016 i najnowsze aktualizacje dostępne tutaj
  • SQL Server 2014 i najnowsze aktualizacje dostępne tutaj
  • SQL Server 2012 i najnowsze aktualizacje dostępne tutaj

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:

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:

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 programu SQL Server hostowania dowolnych baz danych programu Operations Manager, w tym:
    • OperationManager
    • OperationManagerDW
    • Bazy danych usług SSRS ReportServer i ReportServerTempDB
  • Wystąpienie usług 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 domyślne, nadal będzie działać, jeśli żadne konto lokalne nie ma db_owner roli. Konta lokalne z rolą db_owner są znane, aby powodować problemy z programem 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, dzięki czemu będzie mieć dużo wolnego miejsca na dysku powyżej tego podstawowego wymagania.
  • 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 programu SQL Server jest wymagane dla wszystkich wystąpień aparatu bazy danych programu SQL Server hostowania dowolnych baz danych programu 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

Sortowanie 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
  • Chinese_Traditional_Stroke_Count_100_CI_AS
  • Japanese_CI_AS
  • Japanese_XJIS_100_CI_AS
  • Traditional_Spanish_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 obsługiwanych sortowania wymienionych wcześniej, wykonanie nowej konfiguracji programu Operations Manager zakończy się niepowodzeniem. Jednak uaktualnienie w 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 programu Operations Manager
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 firmy Microsoft (MS RPC)
— Instrumentacja zarządzania Windows (WMI)
— Koordynator transakcji rozproszonych firmy Microsoft (MS DTC)		 TCP 135 Przychodzący serwer zarządzania
Odbiornik zawsze włączonej grupy dostępności 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 Operacje

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 zawsze włączoną grupę dostępności SQL, zdefiniowany jest niestandardowy port i powinien być udokumentowany do celów referencyjnych, tak aby 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 obszaru wystąpienia serwery zarządzania muszą wprowadzić więcej zapytań do bazy danych w celu obliczenia zmian konfiguracji i grupowania. Częstotliwość zmian przestrzeni wystąpień zwiększa się podczas importowania nowych pakietów administracyjnych 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że ilości zasobów we/wy magazynu, czasu procesora CPU 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 jest pojedynczym źródłem awarii grupy zarządzania, więc można ją udostępnić w wysokiej dostępności przy użyciu obsługiwanych konfiguracji trybu failover, takich jak zawsze włączone grupy dostępności programu SQL Server lub wystąpienia klastra trybu failover.

Bazy danych programu Operations Manager można skonfigurować i uaktualnić przy użyciu istniejącej konfiguracji zawsze włączonej bazy danych SQL bez konieczności wprowadzania 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 na tym serwerze było wystarczająca pojemność, która obsługuje zapisywanie wszystkich danych zbieranych do magazynu danych. Podobnie jak w przypadku bazy danych programu Operations Manager, najbardziej krytycznym zasobem w magazynie danych jest podsystem we/wy magazynu. 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 umieszczone w magazynie danych przez raportowanie różni się od obciążenia umieszczonego w bazie danych programu Operations Manager według użycia konsoli Operacje.

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 oddzielenie ich od skalowania w górę 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 grupy zarządzania, więc można ją udostępnić w wysokiej dostępności przy użyciu obsługiwanych konfiguracji trybu failover, takich jak zawsze włączone grupy dostępności programu SQL Server lub wystąpienia klastra trybu failover.

Zawsze włączony program SQL Server

Zawsze włączone grupy dostępności programu SQL Server obsługują środowiska trybu failover dla dyskretnego zestawu baz danych użytkowników (baz danych dostępności). Każdy zestaw baz danych dostępności jest hostowany w repliki dostępności.

W programie System Center 2016 i nowszym — Operations Manager zawsze włączone jest preferowane klastrowanie trybu failover w celu zapewnienia wysokiej dostępności baz danych. 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 trybu failover systemu Windows Server (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.

Napiwek

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

Aby skonfigurować grupę dostępności, należy wdrożyć klaster trybu failover systemu Windows Server (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.

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

Program Operations Manager nie obsługuje słów kluczowych parametry 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 czasu wygaśnięcia 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 odbiornika grupy dostępności, zobacz dokumentację tutaj: Konfigurowanie odbiornika grupy dostępności — zawsze włączone programu SQL Server.

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ł BAZY wiedzy Usługa System Center Management przestaje odpowiadać po przejściu wystąpienia programu SQL Server do trybu 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 nie zgodnie z zalecanymi wskazówkami dotyczącymi konfiguracji z aprowizowaną magazynem dla wystąpienia bazy danych programu SQL Server. Oto następujące przykłady:

  • Niewystarczająca alokacja wrzecion dla jednostek LUN w celu obsługi wymagań we/wy programu Operations Manager.
  • Hostowanie dzienników transakcji i plików bazy danych na tym samym woluminie. Te dwa obciążenia mają różne charakterystyki operacji we/wy 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 programu SQL Server przez przeprowadzenie testów przepływności podsystemu we/wy przed wdrożeniem programu SQL Server. Upewnij się, że te testy są w stanie spełnić wymagania dotyczące operacji we/wy z dopuszczalnym opóźnieniem. Użyj narzędzia Diskspd, aby ocenić pojemność we/wy podsystemu magazynowania obsługującego program SQL Server. Poniższy artykuł w blogu, utworzony przez członka zespołu serwera plików w grupie produktów, zawiera szczegółowe wskazówki i zalecenia dotyczące wykonywania testów obciążeniowych przy użyciu tego narzędzia — DiskSpd, PowerShell i wydajności magazynu: mierzenie operacji we/wy, przepływność i opóźnienie 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. Niepowodzenie w tym celu może prowadzić do znacznego obniżenia wydajności i jest najczęściej wynikiem niezgodności partycji z granicami jednostek rozłożonych. Może to również prowadzić do niezgodności pamięci podręcznej sprzętowej, co powoduje nieefektywne wykorzystanie 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 tylko do odczytu na skompresowanych woluminach, nie jest 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ą stronicować dysk. 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żdy zainstalowany 8 GB pamięci RAM (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 przy 96 MB, więc idealnie licznik nie powinien działać niż około 200–300 MB, aby upewnić się, że masz 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 wziąć pod uwagę określone wymagania dotyczące pamięci dla systemu operacyjnego, innych aplikacji, stosu wątków programu 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. Wartość maksymalnego wątku roboczego można znaleźć w kolumnie max_worker_count 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 uzyskać dostęp do punktu, w którym przydział mniejszej ilości pamięci jest wymieniany w celu uzyskania wyższego dostępu we/wy dysku.

Aby skonfigurować pamięć programu SQL Server w środowisku, które zostało nadmiernie aprowidowane, zacznij od monitorowania środowiska i bieżących metryk wydajności, w tym średniej długości życia strony Menedżera programu SQL Server oraz odczytów/s i odczytów/s dysku fizycznego/s wartości. Jeśli środowisko ma nadmiar pamięci, oczekiwana długość życia strony zwiększy się o wartość jednej sekundy bez żadnego spadku obciążenia ze względu na buforowanie; na stronie Menedżera programu SQL Server odczytuje/s wartość będzie niska po podwyższeniu pamięci podręcznej, a odczyty dysku fizycznego na sekundę 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.

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. Jeśli na przykład rozmiar zdefiniowany dla bazy danych TempDB jest zbyt mały, część obciążenia przetwarzania systemu może zostać podjęta z automatycznym zwiększaniem bazy danych TempDB do rozmiaru wymaganego do obsługi obciążenia przy każdym ponownym uruchomieniu wystąpienia programu 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 użyć największego pliku więcej dla alokacji GAM zamiast rozkładać alokacje między wszystkie pliki, tym samym pokonują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" (udostępniona strona mapy alokacji globalnej). 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ę -T1118 śledzenia w parametrach uruchamiania dla programu SQL Server, aby flaga śledzenia pozostała w mocy nawet po recyklingu 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 wystąpieniu 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 operacyjnej, magazynu danych, a nawet bazy danych inspekcji nie obejmują opcji MAXDOP, ponieważ podczas instalacji nie ma możliwości dynamicznego wykonywania zapytań o liczbę procesorów prezentowanych w systemie operacyjnym, ani nie próbuje zakodować wartości tego ustawienia, co może mieć negatywne konsekwencje w przypadku wykonania 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 select * from sys.dm_os_taskszapytanie .

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 utrzymuje się. 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. Chociaż pomocnik ustalania rozmiaru programu Operations Manager jest rozsądny w szacowaniu potencjalnego wzrostu na podstawie formuły uzyskanej przez grupę produktów z testów w laboratorium, nie bierze pod uwagę kilku czynników, co może mieć wpływ na wzrost w najbliższej perspektywie w porównaniu z długoterminowym.

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 pobudzenie wzrostu i rozpocząć rozwiązywanie problemów, aby określić przyczynowość, niezależnie od tego, czy usterka w przepływie pracy pakietu administracyjnego (czyli reguła odnajdywania, reguła wydajności lub zbierania zdarzeń, monitor lub reguła alertu) lub inny objaw pakietu administracyjnego, który nie został zidentyfikowany podczas fazy testowania i zapewnienia jakości procesu 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łączonym automatycznym zwiększaniem; są dostępne tylko bazy danych magazynu danych i usług ACS.

Polegaj tylko na automatycznym zwiększaniu jako awaryjnej sytuacji nieoczekiwanego wzrostu. 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 zwiększania.

Jeśli opcje autogrow i autoshrink są łączone, może to spowodować 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 automatycznym uruchomieniu i zmniejszeniu dziennika 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.

Zasady trybu failover klastra

Klaster trybu failover systemu Windows Server to platforma wysokiej dostępności, która stale monitoruje 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 niezredukowanego sprzętu lub zasilania. W takich sytuacjach serwer zostanie utracony i celem jest klastrowanie trybu failover, aby szybko wykryć utratę serwera i szybko odzyskać 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 zachowanie dla większości klientów; jednak, ponieważ klastry są rozciągane od cali do prawdopodobnie mil od siebie, klaster może stać się narażony na więcej, a potencjalnie zawodne, składniki sieciowe między węzłami. Innym czynnikiem jest to, że jakość serwerów towarowych stale rośnie, w połączeniu z rozszerzoną odpornością za pośrednictwem nadmiarowych składników (takich jak podwójne zasilacze, tworzenie zespołu kart interfejsu sieciowego i wielościeżkowe we/wy), liczba niepowodzeń sprzętowych może być potencjalnie 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 i bazy danych magazynu danych w bezpośrednim dołączonym magazynie, a nie na dysku wirtualnym. Możesz użyć narzędzia Pomocnika określania rozmiaru programu Operations Manager wydanego dla programu Operations Manager 2012, aby oszacować wymagane operacje we/wy na sekundę i przetestować obciążenia dysków danych w celu zweryfikowania. Wydajność magazynu 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.

Zawsze włączone i model odzyskiwania

Chociaż nie jest to ściśle optymalizacja, ważną kwestią dotyczącą zawsze włączonej grupy dostępności jest fakt, że zgodnie z projektem ta funkcja wymaga ustawienia baz danych w modelu 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

Wystąpienie usług Reporting Services działa jako serwer proxy dostępu do danych w bazie danych magazynu 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 istnieje wystąpienie bazy danych programu SQL Server, które hostuje bazy danych ReportServer i ReportServerTempDB. Mają zastosowanie ogólne zalecenia dotyczące dostrajania wydajności tego wystąpienia.

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 wystąpieniem usług Reporting Services.
  3. Kliknij prawym przyciskiem myszy wystąpienie serwera w oknie Eksplorator obiektów.
  4. Wybierz Właściwości.
  5. Wybierz pozycję Zaawansowane na lewym pasku bocznym.
  6. Dodaj *.* element 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ę.