Configuration Manager wytycznych dotyczących rozmiaru i wydajności lokacji
Dotyczy: programu Configuration Manager (bieżąca gałąź)
Configuration Manager liderem w branży pod względem skali i wydajności. Inna dokumentacja obejmuje maksymalne obsługiwane limity skalowania i wytyczne sprzętowe dotyczące uruchamiania lokacji w największych rozmiarach środowisk. Ten artykuł zawiera dodatkowe wskazówki dotyczące wydajności dla środowisk o różnych rozmiarach. Te wskazówki mogą pomóc w dokładniejszym oszacowaniu sprzętu potrzebnego do wdrożenia Configuration Manager.
Ten artykuł koncentruje się na największym współautorze Configuration Manager wąskich gardeł wydajności: podsystemie wejścia/wyjścia dysku lub operacji we/wy na sekundę.
- Przedstawia szczegóły i wyniki testów skoncentrowane na operacji we/wy na sekundę
- Dokumenty dotyczące odtwarzania testów przy użyciu własnych środowisk i sprzętu
- Sugeruje wymagania dotyczące operacji we/wy na sekundę dysku dla różnych środowisk rozmiaru
Metodologia testu wydajnościowego
Można wdrożyć Configuration Manager na wiele unikatowych sposobów, ale ważne jest, aby zrozumieć kilka zmiennych w dyskusjach dotyczących rozmiaru. Jedną ze zmiennych jest interwał funkcji, taki jak cykl spisu. Inną zmienną jest liczba użytkowników, wdrożeń oprogramowania lub innych obiektów , do których system odwołuje się lub wdraża. Testowanie wydajności stosuje te zmienne w ramach obciążenia. Obciążenie generuje obiekty w typowym tempie dla klientów korporacyjnych korzystających z wdrożeń produkcyjnych w środowiskach o różnych rozmiarach.
Uwaga
Dane użycia klientów umożliwiają testowanie bieżących kompilacji gałęzi przy użyciu najbardziej typowych scenariuszy, konfiguracji i ustawień dla większości klientów. Zalecenia przedstawione w tym artykule są oparte na tych średnich. Środowiska mogą się różnić w zależności od rozmiaru i konfiguracji środowiska. Ogólnie rzecz biorąc, Configuration Manager wymaga zdrowego rozsądku, jeśli chodzi o obiekty i interwały. To, że możesz zebrać każdy plik w systemie lub ustawić interwał dla cyklu na jedną minutę, nie oznacza, że powinieneś.
W poniższych sekcjach przedstawiono niektóre kluczowe ustawienia i konfiguracje do użycia podczas testowania i modelowania potrzeb przetwarzania dla dużych przedsiębiorstw. Te wytyczne ułatwiają ustawianie podstawowych oczekiwań dotyczących wydajności systemu dla sugerowanych rozmiarów sprzętu.
Ustawienia interwałów funkcji
Większość testów powinna używać domyślnych interwałów dla kluczowych cykli w systemie. Na przykład testowanie spisu sprzętu odbywa się raz w tygodniu z większym niż domyślnym plikiem mof . Niektóre cykliczne interwały funkcji, zwłaszcza cykle spisu sprzętu i oprogramowania, mogą mieć znaczący wpływ na charakterystykę wydajności środowiska. Środowiska, które umożliwiają agresywne domyślne interwały zbierania danych, wymagają dużego sprzętu w bezpośredniej proporcji do wzrostu aktywności. Załóżmy na przykład, że masz 25 000 klientów stacjonarnych i chcesz zebrać spis sprzętu dwa razy szybciej niż domyślny interwał. Zacznij od zmiany rozmiaru sprzętu witryny tak, jakbyś miał 50 000 klientów.
Obiektów
Testy powinny używać górnej średniej obiektów, których duże przedsiębiorstwa mają tendencję do używania z systemem. Typowe wartości to tysiące kolekcji i aplikacji, które są wdrażane dla setek tysięcy użytkowników lub systemów. Testy powinny być uruchamiane jednocześnie na wszystkich obiektach w systemie w tych limitach. Wielu klientów korzysta z kilku funkcji, ale zazwyczaj nie używa wszystkich funkcji produktu w tych górnych limitach. Testowanie ze wszystkimi funkcjami produktu pomaga zapewnić najlepszą możliwą wydajność w całym systemie i umożliwia buforowanie funkcji, których niektórzy klienci mogą używać powyżej średniej.
Obciążenia
Testy powinny być również uruchamiane na obciążeniach większych niż standardowe średnie dzienne , wykonując symulacje generujące szczytowe zapotrzebowanie na użycie w systemie. Jednym z przykładów jest symulowanie wprowadzania poprawek we wtorek, aby upewnić się, że system może natychmiast zwrócić dane zgodności aktualizacji w tych dniach szczytowej aktywności. Innym przykładem jest symulowanie aktywności witryny podczas powszechnego wybuchu złośliwego oprogramowania, aby zapewnić możliwość terminowego powiadamiania i reagowania. Mimo że wdrożone maszyny o zalecanym rozmiarze mogą być niedostatecznie wykorzystane w danym dniu, bardziej ekstremalne sytuacje wymagają pewnego buforu przetwarzania.
Konfiguracji
Przeprowadzanie testów na różnych urządzeniach fizycznych, funkcji Hyper-V i na platformie Azure z połączeniem obsługiwanych systemów operacyjnych i wersji SQL Server. Zawsze weryfikuj najgorsze przypadki obsługiwanej konfiguracji. Ogólnie rzecz biorąc, funkcja Hyper-V i platforma Azure zwracają porównywalne wyniki wydajności do równoważnego sprzętu fizycznego po skonfigurowaniu w podobny sposób. Bieżące systemy operacyjne serwera zwykle mają wydajność równą lub lepszą niż wcześniejsze wersje systemu operacyjnego. Chociaż wszystkie obsługiwane platformy spełniają minimalne wymagania, zazwyczaj najnowsze wersje produktów pomocniczych, takich jak Windows i SQL Server, zapewniają jeszcze lepszą wydajność.
Największa odmiana pochodzi z SQL Server używanych wersji. Aby uzyskać więcej informacji na temat wersji SQL Server, zobacz Jaka wersja SQL Server powinna zostać uruchomiona?.
Kluczowe czynniki determinujące wydajność
Możesz testować i mierzyć wydajność Configuration Manager przy użyciu różnych rodzajów ustawień, na różne sposoby i w różnych rozmiarach lokacji. Następujące ustawienia i obiekty mogą znacząco wpłynąć na wydajność. Pamiętaj, aby wziąć je pod uwagę podczas testowania i modelowania wydajności w środowisku.
Uwaga
Chociaż niewiele aspektów Configuration Manager ma oficjalne maksimum lub limity interfejsu użytkownika, które zapobiegają nadmiernemu użyciu, wykraczanie poza wytyczne może mieć znaczący negatywny wpływ na wydajność witryny. Przekroczenie zalecanych poziomów lub ignorowanie wskazówek dotyczących ustalania rozmiaru zwykle wymaga większego sprzętu i może spowodować, że środowisko będzie nie do utrzymania, dopóki nie zmniejszy się częstotliwość lub liczba różnych obiektów.
Spis sprzętu
Aby przetestować wydajność punktu odniesienia, ustaw kolekcję spisu sprzętu raz w tygodniu z domyślnym rozmiarem pliku mof oraz około 20% innymi właściwościami. Nie włączaj wszystkich właściwości i zbieraj tylko potrzebne właściwości. Podczas zbierania właściwości, takich jak dostępna pamięć wirtualna, należy zwrócić szczególną uwagę, która będzie zawsze zmieniać się wraz z każdym cyklem spisu. Zbieranie tych właściwości może powodować nadmierne zmiany w każdym cyklu spisu z każdego klienta.
Spis oprogramowania
Aby przetestować wydajność punktu odniesienia, ustaw kolekcję spisu oprogramowania raz w tygodniu, korzystając tylko ze szczegółów produktu . Zbieranie wielu plików może znacznie obciążać podsystem spisu. Unikaj określania filtrów, które mogą zbierać tysiące plików na wielu klientach, takich jak *.exe lub *.dll.
Kolekcje
Podstawowe testy wydajności mogą obejmować kilka tysięcy kolekcji z różnymi rodzajami zakresu, rozmiaru, złożoności i ustawień aktualizacji. Wydajność witryny nie jest bezpośrednią funkcją samej liczby kolekcji w witrynie. Wydajność jest również produktem złożonym zapytań kolekcji, pełnymi i przyrostowymi aktualizacjami oraz częstotliwością zmian, zależnościami między kolekcjami i liczbą klientów w kolekcjach.
Jeśli to możliwe, zminimalizuj kolekcje, które mają kosztowne lub skomplikowane zapytania reguł dynamicznych. W przypadku kolekcji, które wymagają tego typu reguł, ustaw odpowiednie interwały aktualizacji i czas aktualizacji, aby zminimalizować wpływ ponownej oceny kolekcji na system. Na przykład zaktualizuj o północy zamiast 8:00.
Włączenie aktualizacji przyrostowych w kolekcjach zapewnia szybkie i terminowe aktualizacje członkostwa w kolekcji. Mimo że aktualizacje przyrostowe są wydajne, nadal obciążają system. Zrównoważ oczekiwaną częstotliwość zmian z zapotrzebowaniem na aktualizacje członkostwa niemal w czasie rzeczywistym. Załóżmy na przykład, że spodziewasz się dużego współczynnika zmian w elementach członkowskich kolekcji, ale nie potrzebujesz aktualizacji członkostwa niemal w czasie rzeczywistym. Jest to bardziej wydajne i powoduje mniejsze obciążenie systemu w celu zaktualizowania kolekcji za pomocą zaplanowanej pełnej aktualizacji w pewnym interwale niż w celu włączenia aktualizacji przyrostowych.
Po włączeniu aktualizacji przyrostowych zmniejsz liczbę zaplanowanych pełnych aktualizacji w tych samych kolekcjach. Są one jedynie metodą oceny kopii zapasowej, ponieważ aktualizacje przyrostowe powinny aktualizować członkostwo w kolekcji niemal w czasie rzeczywistym. Najlepsze rozwiązania dotyczące kolekcji zalecają maksymalną liczbę kolekcji dla aktualizacji przyrostowych, ale jak wskazuje artykuł, środowisko może się różnić w zależności od wielu czynników.
Kolekcje z regułami członkostwa bezpośredniego i z kolekcją ograniczającą, która nie wykonuje aktualizacji przyrostowych, nie wymagają zaplanowanych pełnych aktualizacji. Wyłącz harmonogramy aktualizacji dla tych typów kolekcji, aby zapobiec niepotrzebnemu obciążeniu systemu. Jeśli kolekcja ograniczająca używa aktualizacji przyrostowych, kolekcje z regułami członkostwa bezpośredniego mogą nie odzwierciedlać aktualizacji członkostwa przez maksymalnie 24 godziny lub do czasu zaplanowanego odświeżania.
Chociaż nie jest to najlepsze rozwiązanie, niektóre organizacje tworzą setki, a nawet tysiące kolekcji w ramach różnych procesów biznesowych. Jeśli używasz automatyzacji do tworzenia kolekcji, ważne jest, aby poprawnie włączyć wszystkie wymagane aktualizacje przyrostowe. Zminimalizuj i rozłóż wszystkie pełne harmonogramy aktualizacji, aby uniknąć punktów gorącej oceny kolekcji w jednym okresie. Ustanawianie regularnego procesu pielęgnacji w celu usunięcia nieużywanych kolekcji, zwłaszcza jeśli automatycznie utworzysz kolekcje, które nie będą już potrzebne po pewnym czasie.
Należy pamiętać, że Configuration Manager tworzy zasady dla wszystkich obiektów w kolekcjach podczas wykonywania zadań docelowych, takich jak wdrożenia. Zmiany członkostwa za pomocą zaplanowanego odświeżania lub aktualizacji przyrostowych mogą tworzyć znacznie więcej pracy dla całego systemu. Najnowsze kompilacje bieżącej gałęzi mają specjalne optymalizacje zasad dla kolekcji Wszystkie systemy i Wszyscy użytkownicy. W przypadku określania wartości docelowej dla całego przedsiębiorstwa użyj wbudowanych kolekcji zamiast klonowania tych wbudowanych kolekcji.
Aby jeszcze bardziej zbadać wydajność kolekcji, wyświetl ocenę kolekcji w konsoli programu . Aby uzyskać więcej informacji, zobacz Jak wyświetlić ocenę kolekcji.
Metody odnajdywania
W przypadku podstawowych testów wydajnościowych należy uruchamiać metody odnajdywania oparte na serwerze raz w tygodniu, umożliwiając odnajdywanie różnic odpowiednio do przechowywania danych w ciągu tygodnia. Testy powinny odnajdywać ilość obiektu proporcjonalną do symulowanego rozmiaru przedsiębiorstwa. Test punktu odniesienia wydajności dla odnajdywania pulsu powinien być również uruchamiany raz w tygodniu.
Dane odnajdywania to dane globalne. Typowym problemem związanym z wydajnością jest błędna konfiguracja metod odnajdywania opartych na serwerze w hierarchii, co powoduje zduplikowane odnajdywanie tych samych zasobów z wielu lokacji głównych. Starannie skonfiguruj metody odnajdywania, aby zoptymalizować komunikację z usługą docelową, taką jak kontrolery domeny usługi Active Directory, unikając duplikowania tego samego zakresu odnajdywania w wielu lokacjach głównych.
Ogólne wytyczne dotyczące ustalania rozmiaru
W oparciu o poprzednią metodologię testów wydajności poniższa tabela zawiera ogólne minimalne wytyczne dotyczące wymagań sprzętowych dla określonej liczby zarządzanych klientów. Te wartości powinny zezwalać większości klientów z określoną liczbą klientów na przetwarzanie obiektów wystarczająco szybko, aby administrować określoną lokacją. Moc obliczeniowa co roku stale spada, a niektóre z poniższych wymagań są niewielkie w przypadku nowoczesnych konfiguracji sprzętu serwera. Sprzęt, który przekracza poniższe wytyczne, proporcjonalnie zwiększa wydajność lokacji, które wymagają większej mocy obliczeniowej lub mają specjalne wzorce użycia produktów.
| Klienci klasyczni | Typ/rola witryny | Rdzenie — uwaga 1 | Pamięć (GB) | SQL Server alokacji pamięci Uwaga 2 | Liczby operacji we/wy na sekundę: skrzynki odbiorcze — uwaga 3 | Operacje we/wy na sekundę: SQL Server Uwaga 3 | Wymagane miejsce do magazynowania (GB) Uwaga 4 |
|---|---|---|---|---|---|---|---|
| 25 tys. | Podstawowa lub CAS z rolą lokacji bazy danych na tym samym serwerze | 6 | 24 | 65% | 600 | 1700 | 350 |
| 25 tys. | Podstawowa lub CAS | 4 | 8 | 600 | 100 | ||
| Zdalne SQL Server | 4 | 16 | 70% | 1700 | 250 | ||
| 50 tys. | Podstawowa lub CAS z rolą lokacji bazy danych na tym samym serwerze | 8 | 32 | 70% | 1200 | 2800 | 600 |
| 50 tys. | Podstawowa lub CAS | 4 | 8 | 1200 | 200 | ||
| Zdalne SQL Server | 8 | 24 | 70% | 2800 | 400 | ||
| 100 tys. | Podstawowa lub CAS z rolą lokacji bazy danych na tym samym serwerze | 12 | 64 | 70% | 1200 | 5000 | 1100 |
| 100 tys. | Podstawowa lub CAS | 6 | 12 | 1200 | 300 | ||
| Zdalne SQL Server | 12 | 48 | 80% | 5000 | 800 | ||
| 150 tys. | Podstawowa lub CAS z rolą lokacji bazy danych na tym samym serwerze | 16 | 96 | 70% | 1800 | 7400 | 1600 |
| 150 tys. | Podstawowa lub CAS | 8 | 16 | 1800 | 400 | ||
| Zdalne SQL Server | 16 | 72 | 90% | 7400 | 1200 | ||
| 700 tys. | CAS z rolą lokacji bazy danych na tym samym serwerze | 20+ | 128+ | 80% | 1800+ | 9000+ | 5000+ |
| 700 tys. | Cas | 8+ | 16+ | 1800+ | 500+ | ||
| Zdalne SQL Server | 16+ | 96+ | 90% | 9000+ | 4500+ | ||
| 5 tys. | Lokacja dodatkowa | 4 | 8 | 500 | - | 200 | |
| 15 tys. | Lokacja dodatkowa | 8 | 16 | 500 | - | 300 |
Uwagi dotyczące ogólnych wytycznych dotyczących ustalania rozmiaru
Uwaga 1. Rdzenie
Configuration Manager uruchamia wiele jednoczesnych procesów, więc wymaga pewnej minimalnej liczby rdzeni procesora CPU dla różnych rozmiarów lokacji. Rdzenie są z roku na rok szybsze, ale ważne jest, aby zapewnić równoległą pracę określonej minimalnej liczby rdzeni. Ogólnie rzecz biorąc, każdy procesor cpu na poziomie serwera utworzony po 2015 r. spełnia podstawowe wymagania dotyczące wydajności rdzeni określonych w tabeli. Configuration Manager korzysta z innych rdzeni poza zaleceniami. Po utworzeniu minimalnych sugerowanych rdzeni należy określić priorytet inwestycji w zasoby procesora CPU, aby zwiększyć szybkość istniejących rdzeni. Nie dodaj więcej, wolniejsze rdzenie. Na przykład Configuration Manager ma lepszą wydajność w przypadku zadań przetwarzania kluczy z 16 szybkimi rdzeniami niż w przypadku 24 wolniejszych rdzeni. Ta wydajność zakłada, że istnieje wystarczająca ilość innych zasobów systemowych, takich jak operacje we/wy na sekundę dysku.
Ważna jest również relacja między rdzeniami i pamięcią. Ogólnie rzecz biorąc, posiadanie mniej niż 3–4 GB pamięci RAM na rdzeń zmniejsza całkowitą możliwość przetwarzania na serwerach SQL Server. Potrzebujesz więcej pamięci RAM na rdzeń, gdy SQL Server jest kolokowana ze składnikami serwera lokacji.
Uwaga
Wszystkie testy ustawiają plany zasilania maszyny, aby umożliwić maksymalne zużycie i wydajność procesora CPU.
Uwaga 2: alokacja pamięci SQL Server
Ta wartość służy do konfigurowania maksymalnej pamięci serwera (w MB) we właściwościach SQL Server. Jest to procent całkowitej ilości pamięci dostępnej na serwerze.
Nie konfiguruj wartości minimalnych i maksymalnych tak samo. Te wskazówki dotyczą w szczególności maksymalnej ilości pamięci, którą należy zezwolić SQL Server na przydzielanie.
Uwaga 3. Operacje we/wy na sekundę: skrzynki odbiorcze i operacje we/wy na sekundę: SQL
Te wartości odnoszą się do potrzeb operacji we/wy na sekundę dla dysków logicznych Configuration Manager i SQL Server. Kolumna IOPS: Inboxes przedstawia wymagania dotyczące operacji we/wy na sekundę dla dysku logicznego z katalogami skrzynki odbiorczej Configuration Manager. Kolumna IOPS: SQL przedstawia łączną liczbę operacji we/wy na sekundę dla dysków logicznych używanych przez różne pliki SQL Server. Te kolumny są różne, ponieważ oba dyski powinny mieć różne formatowanie. Aby uzyskać więcej informacji i przykładów dotyczących sugerowanych SQL Server konfiguracji dysków i najlepszych rozwiązań dotyczących plików, w tym szczegółowych informacji na temat dzielenia plików na wiele woluminów, zobacz Często zadawane pytania dotyczące ustalania rozmiaru i wydajności witryny.
Obie te kolumny operacji we/wy na sekundę używają danych z standardowego w branży narzędzia Diskspd. Aby uzyskać instrukcje dotyczące duplikowania tych pomiarów, zobacz Jak mierzyć wydajność dysku . Ogólnie rzecz biorąc, po spełnieniu podstawowych wymagań dotyczących procesora CPU i pamięci podsystem magazynu ma największy wpływ na wydajność lokacji, a ulepszenia zapewnią największy zwrot z inwestycji.
Uwaga 4. Wymagane miejsce do magazynowania
Te rzeczywiste wartości mogą różnić się od innych udokumentowanych zaleceń. Podajemy te liczby tylko jako ogólne wytyczne; poszczególne wymagania mogą się znacznie różnić. Przed instalacją lokacji dokładnie zaplanuj potrzeby dotyczące miejsca na dysku. Załóżmy, że przez większość czasu część tego magazynu pozostaje jako wolne miejsce na dysku. Tego miejsca buforu można użyć w scenariuszu odzyskiwania lub w scenariuszach uaktualniania, które wymagają wolnego miejsca na dysku na potrzeby rozszerzania pakietu instalacyjnego. Witryna może wymagać więcej miejsca do zbierania dużych ilości danych, dłuższych okresów przechowywania danych i dużych ilości zawartości dystrybucji oprogramowania. Te elementy można również przechowywać w oddzielnych woluminach o niższej przepływności.
Jak mierzyć wydajność dysku
Możesz użyć standardowego w branży narzędzia Diskspd, aby udostępnić ustandaryzowane sugestie dotyczące liczby operacji we/wy na sekundę, których wymagają środowiska Configuration Manager o różnych rozmiarach. Poniższe kroki testowe i wiersze polecenia nie są wyczerpujące, ale zapewniają prosty i powtarzalny sposób szacowania przepływności podsystemu dysków serwerów. Wyniki można porównać z minimalną zalecaną operacją we/wy na sekundę w tabeli ogólnych wytycznych dotyczących ustalania rozmiaru .
Aby uzyskać wyniki testów z różnych rodzajów konfiguracji sprzętu w środowiskach laboratoryjnych, zobacz Przykładowe konfiguracje dysków. Dane można użyć dla punktu początkowego przy projektowaniu podsystemu magazynu dla nowego środowiska od podstaw.
Jak przetestować operacje we/wy na sekundę dysku
Pobierz narzędzie Diskspd.
Upewnij się, że masz co najmniej 100 GB wolnego miejsca na dysku. Wyłącz wszystkie aplikacje, które mogą zakłócać działanie dysku lub powodować dodatkowe obciążenie, takie jak aktywne skanowanie antywirusowe katalogu, programu SQL lub SMSExec.
Uruchom narzędzie Diskspd z wiersza polecenia z podwyższonym poziomem uprawnień.
Uruchom narzędzie dwa razy w kolejności dla woluminu, który chcesz przetestować. Pierwszy test o rozmiarze 64 tys. z losowymi operacjami zapisu przez minutę. Ten test sprawdza poprawność ładowania pamięci podręcznej kontrolera i alokacji miejsca na dysku, jeśli wolumin jest dynamicznie rozszerzany. Odrzuć wyniki pierwszego testu. Drugi test powinien natychmiast wykonać pierwszy test i wykonać to samo obciążenie przez pięć minut.
Na przykład użyj następujących wierszy polecenia, aby przetestować
G:wolumin.DiskSpd.exe -r -w100 -t8 -o8 -b64K -c100G -d60 -h -L G:\\test\testfile.dat del G:\\test\testfile.dat DiskSpd.exe -r -w100 -t8 -o8 -b64K -c100G -d300 -h -L G:\\test\testfile.datPrzejrzyj dane wyjściowe z drugiego testu, aby znaleźć łączną liczbę operacji we /wy w kolumnie We/Wy na sekundę . W poniższym przykładzie łączna liczba operacji we/wy na sekundę wynosi 3929,18.
Total IO | thread | bytes | I/Os | MB/s | I/O per s | AvgLat | LatStdDev | |--------|-------------|---------|--------|-----------|--------|-----------| | 1 | 9651814400 | 147275 | 30.68 | 490.92 | 16.294 | 10.210 | | 2 | 9676652544 | 147654 | 30.76 | 492.18 | 16.252 | 9.998 | | 3 | 9638248448 | 147068 | 30.64 | 490.23 | 16.317 | 10.295 | | 4 | 9686089728 | 147798 | 30.79 | 492.66 | 16.236 | 10.072 | | 5 | 9590931456 | 146346 | 30.49 | 487.82 | 16.398 | 10.384 | | 6 | 9677242368 | 147663 | 30.76 | 492.21 | 16.251 | 10.067 | | 7 | 9637330944 | 147054 | 30.64 | 490.18 | 16.319 | 10.249 | | 8 | 9692577792 | 147897 | 30.81 | 492.99 | 16.225 | 10.125 | | Total: | 77250887680 | 1178755 | 245.57 | 3929.18 | 16.286 | 10.176 |
Przykładowe konfiguracje dysków
W poniższych tabelach przedstawiono wyniki wykonywania kroków testu w temacie Jak mierzyć wydajność dysku przy użyciu różnych konfiguracji laboratoriów testowych. Użyj tych danych, aby uzyskać trudny punkt początkowy podczas projektowania podsystemu magazynu dla nowego środowiska od podstaw.
Maszyny fizyczne i funkcja Hyper-V
Sprzęt jest zawsze ulepszany. Spodziewaj się, że nowsze generacje sprzętu i różne kombinacje sprzętowe, takie jak dyski SSD i sieci SAN, przekroczą wydajność określoną poniżej. Te wyniki są podstawowym punktem wyjścia do rozważenia podczas projektowania serwera lub omawiania z dostawcą sprzętu.
W poniższej tabeli przedstawiono wyniki testów w różnych podsystemach dysków, w tym na dyskach twardych opartych na dyskach SSD, w różnych konfiguracjach laboratoriów testowych. Wszystkie konfiguracje formatują dyski z klastrami 64k i dołączają je do kontrolera dysków klasy korporacyjnej. Oprócz liczby dysków macierzy RAID każdy z nich ma co najmniej jeden dysk zapasowy.
| Typ dysku | Liczba dysków, bez +1 dysku zapasowego | RAID | Mierzona liczba operacji we/wy na sekundę |
|---|---|---|---|
| 15 tys. sygnatury dostępu współdzielonego | 2 | 1 | 620 |
| 15 tys. sygnatury dostępu współdzielonego | 4 | 10 | 1206 |
| 15 tys. sygnatury dostępu współdzielonego | 6 | 10 | 1751 |
| 15 tys. sygnatury dostępu współdzielonego | 8 | 10 | 2322 |
| 15 tys. sygnatury dostępu współdzielonego | 10 | 10 | 2882 |
| 15 tys. sygnatury dostępu współdzielonego | 12 | 10 | 3476 |
| 15 tys. sygnatury dostępu współdzielonego | 16 | 10 | 4236 |
| 15 tys. sygnatury dostępu współdzielonego | 20 | 10 | 5148 |
| 15 tys. sygnatury dostępu współdzielonego | 30 | 10 | 7398 |
| 15 tys. sygnatury dostępu współdzielonego | 40 | 10 | 9913 |
| SSD SATA | 2 | 1 | 3300 |
| SSD SATA | 4 | 10 | 5542 |
| SSD SATA | 6 | 10 | 7201 |
| SSD SAS | 2 | 1 | 7539 |
| SSD SAS | 4 | 10 | 14346 |
| SSD SAS | 6 | 10 | 15607 |
W poniższej tabeli wymieniono określone urządzenia używane w tym przykładzie. Te informacje nie są rekomendacją dla żadnego konkretnego modelu sprzętu ani producenta.
| Typ dysku | Modelu | Kontroler RAID | Pamięć podręczna i konfiguracja |
|---|---|---|---|
| 15k RPM SAS HD | HP EH0300JDYTH | Tablica inteligentna P822 | 2 GB, 20% odczytu / 80% zapisu |
| SSD SATA | ATA MK0200GCTYV | Tablica inteligentna P420i | 1 GB, 20% odczytu / 80% zapisu |
| SSD SAS | HP MO0800 JEFPB | Tablica inteligentna P420i | 1 GB, 20% odczytu / 80% zapisu |
Wydajność maszyny i dysku platformy Azure
Wydajność dysków platformy Azure zależy od kilku czynników, takich jak rozmiar maszyny wirtualnej platformy Azure oraz liczba i typ dysków, których używa. Platforma Azure stale dodaje również nowe typy maszyn i szybkości dysków, które różnią się od poniższego wykresu. Aby uzyskać więcej informacji na temat Configuration Manager uruchomionych na platformie Azure oraz dodatkowe informacje na temat opisu operacji we/wy dysku na platformie Azure, zobacz Configuration Manager na platformie Azure — często zadawane pytania.
Wszystkie dyski mają sformatowany rozmiar klastra NTFS 64k, a wiersze z więcej niż jednym dyskiem są konfigurowane jako woluminy rozkładane za pośrednictwem narzędzia do zarządzania dyskami systemu Windows.
| Maszyna wirtualna platformy Azure | Dysk platformy Azure | Liczba dysków | Dostępne miejsce | Mierzona liczba operacji we/wy na sekundę | Czynnik ograniczający |
|---|---|---|---|---|---|
| DS2/DS11 | P20 | 1 | 512 GB | 965 | Rozmiar maszyny wirtualnej platformy Azure |
| DS2/DS11 | P20 | 2 | 1024 GB | 996 | Rozmiar maszyny wirtualnej platformy Azure |
| DS2/DS11 | P30 | 1 | 1024 GB | 996 | Rozmiar maszyny wirtualnej platformy Azure |
| DS2/DS11 | P30 | 2 | 2048 GB | 996 | Rozmiar maszyny wirtualnej platformy Azure |
| DS3/DS12/F4S | P20 | 1 | 512 GB | 1994 | Rozmiar maszyny wirtualnej platformy Azure |
| DS3/DS12/F4S | P20 | 2 | 1024 GB | 1992 | Rozmiar maszyny wirtualnej platformy Azure |
| DS3/DS12/F4S | P30 | 1 | 1024 GB | 1993 | Rozmiar maszyny wirtualnej platformy Azure |
| DS3/DS12/F4S | P30 | 2 | 2048 GB | 1992 | Rozmiar maszyny wirtualnej platformy Azure |
| DS4/DS13/F8S | P20 | 1 | 512 GB | 2334 | Dysk P20 |
| DS4/DS13/F8S | P20 | 2 | 1024 GB | 3984 | Rozmiar maszyny wirtualnej platformy Azure |
| DS4/DS13/F8S | P20 | 3 | 1536 GB | 3984 | Rozmiar maszyny wirtualnej platformy Azure |
| DS4/DS13/F8S | P30 | 1 | 1024 GB | 3112 | Dysk P30 |
| DS4/DS13/F8S | P30 | 2 | 2048 GB | 3984 | Rozmiar maszyny wirtualnej platformy Azure |
| DS4/DS13/F8S | P30 | 3 | 3072 GB | 3996 | Rozmiar maszyny wirtualnej platformy Azure |
| DS5/DS14/F16S | P20 | 1 | 512 GB | 2335 | Dysk P20 |
| DS5/DS14/F16S | P20 | 2 | 1024 GB | 4639 | Dysk P20 |
| DS5/DS14/F16S | P20 | 3 | 1536 GB | 6913 | Dysk P20 |
| DS5/DS14/F16S | P20 | 4 | 2048 GB | 7966 | Rozmiar maszyny wirtualnej platformy Azure |
| DS5/DS14/F16S | P30 | 1 | 1024 GB | 3112 | Dysk P30 |
| DS5/DS14/F16S | P30 | 2 | 2048 GB | 6182 | Dysk P30 |
| DS5/DS14/F16S | P30 | 3 | 3072 GB | 7963 | Rozmiar maszyny wirtualnej platformy Azure |
| DS5/DS14/F16S | P30 | 4 | 4096 GB | 7968 | Rozmiar maszyny wirtualnej platformy Azure |
| DS15 | P30 | 1 | 1024 GB | 3113 | Dysk P30 |
| DS15 | P30 | 2 | 2048 GB | 6184 | Dysk P30 |
| DS15 | P30 | 3 | 3072 GB | 9225 | Dysk P30 |
| DS15 | P30 | 4 | 4096 GB | 10200 | Rozmiar maszyny wirtualnej platformy Azure |
Aby uzyskać więcej informacji na temat obecnie dostępnych dysków, zobacz Wybieranie typu dysku dla maszyn wirtualnych IaaS platformy Azure.