Digi Data - Optymalizacja sprzętu 1C:

1. Jak zwiększyć wydajność systemu dyskowego?
2. Tabele baz danych
3. Pliki indeksu i pliki TempBD
4. Pliki dziennika
5. Optymalny sprzęt dla 1C: jaki powinien być podsystem dysku?
6. Kompromis między niezawodnością a wydajnością

Aby znaleźć najlepszy sprzęt serwerowy dla 1C, będziesz potrzebował przynajmniej zagłębić się w strukturę obciążenia obliczeniowego. Jeśli budżet na zakup sprzętu jest ograniczony, ale zadanie nadal wymaga rozwiązania, główną bronią będzie monitorowanie zachowania głównych podsystemów serwera, przeprowadzanych w rzeczywistych warunkach. Uzupełnij wyniki obserwacji argumentami zdrowego rozsądku - i nie musisz wydawać dodatkowych pieniędzy.

Nawet jeśli niewielka liczba użytkowników pracuje z aplikacją, zużycie zasobów 1C: Enterprise 8 może być dość wysokie. Wybierając najlepszy sprzęt serwerowy dla 1C, każdy właściciel będzie dążył do uniknięcia potencjalnych wąskich gardeł. Z drugiej strony, nawet chęć zapewnienia szybszego 1C częściej niż jest wystarczającym argumentem, aby kupić serwer „dla wzrostu”: nadmiar mocy zamienia się w dodatkowe koszty. Znalezienie pośredniej podstawy nie jest takie trudne: można wcześniej usunąć profil obciążenia i zaprojektować serwer już dla określonej konfiguracji aplikacji.

Aby przeprowadzić merytoryczną rozmowę, weź na przykład platformę 1C: Enterprise 8.2. Jak pokazuje praktyka, sytuacje, w których 1C 8.2 działa powoli, są bardzo powszechne . Rozważymy podstawowe konfiguracje: „Zarządzanie handlem”, „Zarządzanie wynagrodzeniami i personelem”, „Rachunkowość”, „Zarządzanie przedsiębiorstwem handlowym”, a także „Zarządzanie działaniami produkcyjnymi”. W naszych obliczeniach wykorzystamy fakt, że jeśli z platformą pracuje więcej niż 10 pracowników, firma korzysta również z 1C: Enterprise 8.2. Serwer aplikacji. Ponadto załóżmy, że można pracować w trybie Pulpitu zdalnego (pulpit zdalny), liczba użytkowników bazy danych podłączonych jednocześnie - od 100 do 150.

Wybór sprzętu w 1C zgodnie z naszymi zaleceniami jest możliwy dla baz danych o większym zużyciu zasobów, zwracamy jednak uwagę na fakt, że w takich przypadkach optymalizacja pracy 1C jest prawie zawsze przeprowadzana indywidualnie.

Jak zwiększyć wydajność systemu dyskowego?

1C jest wolny. Serwer hamulców 1C. Zbyt długi czas odpowiedzi 1C. Bardzo często takie skargi powstają, ponieważ konfiguracja serwera po prostu nie uwzględniała dokładnie tego, jakie rodzaje operacji we / wy są wykonywane przez sprzęt, które dane wpływają na te operacje oraz z jaką intensywnością są realizowane. Wszystkie te problemy są bezpośrednio związane z podsystemem dyskowym, którego optymalizacja jest często wystarczająca do osiągnięcia normalnej wydajności serwera.

Podczas łączenia dużej liczby użytkowników lub masowej realizacji postów, pobierania i przesyłania, blokowanie tabeli staje się najpoważniejszym problemem dla bazy danych. Aby zrozumieć, jak sobie z tym poradzić, rozważ zasady konstruowania systemu dyskowego dla serwera 1C.

Bazy danych 1C mają pięć strumieni danych dla podsystemów dyskowych.

1. Tabele baz danych.
2. Temp pliki tempDB.
3. Indeksuj pliki.
4. Pliki dziennika SQL i pliki dziennika platformy użytkownika.

Organizacja pracy z każdym rodzajem strumienia danych ma swoją specyfikę.

Tabele baz danych

W procesie pracy z tabelami bazy danych szczególnie ważne jest, ile operacji zapisu i odczytu może wykonać podsystem dyskowy w określonym przedziale czasu. Liczba tych operacji jest oznaczona jako IOPS. Jednocześnie parametry szybkości przesyłania danych strumieniowych w MBp / s są znacznie mniej ważne. Nawet jeśli 1C działa powoli w sieci, jego wydajność będzie wystarczająca, pod warunkiem, że normalna stawka IOPS.

Jakie są potrzeby IOPS dla baz danych z ilością danych i liczbą użytkowników?

Ta tabela pokazuje wskaźniki szczytowe, które nie zawsze są stałe. Średnie obciążenie systemu dyskowego może wynosić 10-15% z nich. Niemniej jednak konieczne jest skupienie się na maksimum: główną wartością jest wydajność w okresach szczytowych obciążeń, na przykład, gdy dane są automatycznie pobierane z innego systemu, okres jest ponownie przesyłany itd.

Jakie są wskaźniki dla nowoczesnych dysków w operacjach losowego odczytu / zapisu?

Ta tabela pozwala wyciągnąć kilka wniosków.

1. Dla każdego z modeli metryki IOPS dla operacji zapisu są znacznie niższe niż dla operacji odczytu.
2. Dysk SSD znacznie wyprzedza tradycyjny dysk twardy pod względem liczby operacji zapisu i odczytu na jednostkę czasu. Ta różnica utrzymuje się nawet w porównaniu z modelami SSD dla komputerów stacjonarnych, które zostały wydane dawno temu (IOPS jest o 3–40 wyższe). Serwer SSD pokazuje jeszcze wyższe stawki: IOPS jest 12-40 razy wyższy w porównaniu z HDD.
3. Klasa SSD Intel 910 lub LSI WarpDrive - najlepsza odpowiedź na pytanie, jak zwiększyć wydajność 1C: dyski te mają maksymalną wydajność IOPS.

Jeśli jednym z zadań jest optymalizacja działania bazy danych, warto wziąć pod uwagę, że podczas budowy podsystemu dyskowego serwery nie używają pojedynczych dysków, ale macierzy RAID. Nakłada to pewne specyfikacje na obliczanie rzeczywistej wydajności podsystemu dyskowego: należy wziąć pod uwagę dokładnie, jakie koszty zapisu do IOPS są ponoszone przez grupę dysków w tablicy.

Wartość w kolumnie to IOPS dysku fizycznego, który będzie wymagany do zapisu lub odczytu danych w tablicy. Weź przykład RAID 5. Aby napisać 1 IOPS, potrzebujesz 4 dysków fizycznych IOPS.

Wzór na obliczenie wydajności będzie następujący:

Suma IOPS dysków fizycznych grupy RAID / koszt zapisu IOPS, które grupa dysków ponosi w tablicy.

Dwa przykłady wystarczą do wyjaśnienia.

1. 2 dyski twarde SATA 7200 (IOPS = 100) w macierzy RAID 1 z operacjami zapisu dadzą następującą wydajność: (100 + 100) / 2 = 100 IOPS.
2. 4 dyski twarde SATA 7200 (IOPS = 100) w macierzy RAID 5 z operacjami zapisu zapewniają następującą wydajność: (100 + 100 + 100 + 100) / 4 = 100 IOPS.

Proste obliczenia pokazują, że RAID 10 jest najbardziej korzystny do przechowywania baz danych, typowy rozkład operacji odczytu i zapisu, dla którego wynosi 68/32. Jeśli polegamy na wszystkich trzech tabelach, to jest jasne, że w wielu przypadkach powolna praca 1C jest związana z faktem, że „zestaw dżentelmena” składający się z 2 dysków HDD SATA 7200 połączonych w macierz RAID 1 jest używany jako podsystem dysku . Przy szczytowych obciążeniach moc takiego zestawu jest wyraźnie niewystarczająca, a 1C „zwalnia” po prostu dlatego, że rośnie ogromna kolejka dostępu do dysku, w wyniku czego użytkownicy muszą długo czekać na odpowiedź systemu.

Jest więc oczywiste, że głównym zadaniem w odniesieniu do podsystemu dyskowego jest zwiększenie wydajności w odniesieniu do operacji zapisu. To właśnie brak takiej wydajności często staje się przyczyną awarii, przy której zwalnia 1C 8.2. Jak osiągnąć, że serwer pod 1C dał maksymalną liczbę rekordów IOPS? Można to zrobić na kilka sposobów.

1. Zwiększ liczbę dysków w grupie RAID. Jeśli 1C zawiesza się, to rozwiązanie może zwiększyć szybkość operacji zapisu.
2. Zastępowanie istniejących dysków na płyty o wyższych prędkościach (stosowane na dysk twardy).
3. Wykorzystanie grup RAID, w których różnica między macierzą IOPS a napędami fizycznymi IOPS jest minimalna.
4. Używanie pamięci podręcznej kontrolera RAID do przemieszczania danych. W trybie Write Trough dane są zapisywane bezpośrednio na dyskach. Jeśli włączysz tryb zapisu zapisu wstecznego, dane zostaną najpierw zapisane w pamięci podręcznej kontrolera, a następnie w uporządkowanej formie na dyskach. Jeśli 1C 8 jest powolne, technika ta może zwiększyć wydajność zapisu o 30-100%, w zależności od specyfiki zadania.
5. Jeśli baza danych jest spowolniona przez stosunkowo niewielką objętość (do 20 GB) lub niskobudżetową bazę danych, można użyć hybrydowej macierzy RAID, która obejmuje dyski HDD i SSD. W rozproszonych strukturach dla oddziałowych baz danych dla 3-15 użytkowników nie jest już wymagane. Taki wybór sprzętu dla 1C jest możliwy, na przykład, podczas budowy podsystemu dyskowego dla serwera na stacji paliw, kawiarni, w małym sklepie.
6. Jeśli zwalnia 1C z dużą bazą danych (rozmiar to 200 GB i więcej, istnieje duża ilość zapisanych danych „historycznych”), można użyć buforowania SSD. Wykonywany jest przy użyciu technologii Adaptec MaxCache 3.0 i LSI CasheCade 2.0. Właśnie w rozwiązywaniu problemów 1C taka technika pozwala przyspieszyć zapisywanie danych na dyskach o 20-50%.

Macierze RAID zbudowane na dyskach SSD typu serwerowego są liderami pod względem wydajności IOPS. Mogą to być tradycyjne grupy RAID z kontrolerem SAS RAID lub SSD PCIe. Istnieją tylko dwa powody, które uniemożliwiają ich rozpowszechnienie: stosunkowo wysokie koszty i ograniczenia technologiczne. W szczególności wydajność kontrolerów RAID pozostaje w tyle za wydajnością samych dysków SSD serwera. Ponadto, aby korzystać z opisanych macierzy RAID, konieczna jest radykalna zmiana struktury pamięci.

Pliki indeksu i pliki TempBD

Aktualizowanie plików indeksu występuje stosunkowo rzadko - z reguły raz dziennie. Jednocześnie ich czytanie jest powtarzane bardzo często. Biorąc pod uwagę wysokie wymagania dotyczące odczytu IOPS, takie pliki muszą być przechowywane na dysku SSD.

Pliki TempBD służą do przechowywania danych tymczasowych. Zwykle mają małą objętość (od 1 do 12 GB). Jednocześnie stawiają bardzo wysokie wymagania dotyczące wydajności dysku. Warto zauważyć, że utrata takich plików nie prowadzi do utraty rzeczywistych danych, co pozwala na umieszczenie ich na osobnych woluminach (jeden, najlepiej dwa). Jednym z rozwiązań jest wbudowany kontroler SATA płyty głównej.

Jeśli chcesz zapewnić maksymalną stabilność 1C, lepiej jest umieścić TempBD na lustrzanym dysku SSD (w RAID 1). Jeśli plik znajduje się na kontrolerze, konieczne jest wyłączenie wszystkich pamięci podręcznych do zapisu. Jako serwer lustrzany nie jest konieczne korzystanie z serwerów SSD - odpowiednie są dyski stacjonarne (Intel 520 lub odpowiednik).

Jakie będzie usunięcie TempBD z ogólnego systemu pamięci masowej 1C w podsystemie dedykowanym z wyższym IOPS? Po pierwsze - lepsza wydajność, a także lepsza wydajność systemu podczas szczytowych obciążeń.

W przypadku, gdy konieczne jest rozwiązanie złożonych zadań projektowych i istnieje możliwość zapewnienia szybkiej reakcji administratorów na sytuacje, w których zawiesza się 1C, TempBD można przenieść do RAMDrive. Ogólna wydajność systemu w tym przypadku może wzrosnąć o 4-12%. Jedynym zastrzeżeniem, które należy wziąć pod uwagę, jest to, że kiedy uruchamiasz serwer, musisz kontrolować automatyczne uruchamianie RamDrive. Jeśli się nie uruchomi, będziesz potrzebował ręcznego uruchomienia, wykonanego przez administratora. W przeciwnym razie cały system zostanie zatrzymany.

Pliki dziennika

Mówiąc bardzo prosto, pliki dziennika są używane do prowadzenia rejestru działań systemu. W związku z tym prawie nieprzerwanie generują strumień dostępu do zapisu. Przy średnich obciążeniach proces ten nie jest praktycznie odczuwalny, ale w momentach szczytowych obciążeń w systemie obciążenie utworzone przez pliki dziennika może być powodem zawieszenia 1C 8.

Plik dziennika SQL musi zostać przeniesiony do oddzielnego woluminu. Wymagania dla IOPS, aby nie były zbyt wysokie, rekord przejdzie w tryb liniowy. Ponadto można utworzyć lustro na dysku SATA lub NL SAS, wybierając do tego niedrogi nośnik surround. Również w tym celu można wykorzystać komputery stacjonarne z serii SSD Intel 520.

Jak widać, wraz z początkiem używania dysków SSD w podsystemach dyskowych na serwerach pojawiło się wiele możliwości zwiększenia ich wydajności. Wielopoziomowe przechowywanie danych, jak również właściwa organizacja procesu wprowadzania i wyprowadzania danych, pozwalają uniknąć sytuacji, w których 1C 8 zwalnia.

Optymalny sprzęt dla 1C: jaki powinien być podsystem dysku?

Istnieją cztery podstawowe wytyczne dotyczące umieszczania danych różnych typów.

1. Tabele bazy danych muszą znajdować się na dyskach RAID 10 (dla małych baz danych, RAID 1). Jako dyski fizyczne należy używać dysków SSD serwera, które są koniecznie uzupełniane przez sprzętowy kontroler RAID. Jeśli wymagania dotyczące wydajności dla IOPS są wystarczająco wysokie, możliwe jest użycie SSD PCIe. W przypadku masowych baz danych można opcjonalnie użyć buforowania SSD przed bezpośrednim zapisaniem na dysk twardy. Tradycyjna tablica zbudowana na dyskach twardych SAS 15K rpm może być używana pod warunkiem, że wymagania wydajności IOPS nie są zbyt wysokie.
2. W przypadku plików indeksu zaleca się użycie oddzielnego woluminu. Może to być niedrogi, ale szybki dysk SSD. Pliki TempDB najlepiej umieścić na RAMDrive, lub 1 lub 2 SSD w macierzy RAID 1.
3. Przechowywanie danych użytkownika i systemu operacyjnego jest najlepiej na dyskach DDS lub HDD w macierzy RAID 1.
4. Pliki dziennika (zarówno 1C, jak i SQL) powinny być umieszczone na dedykowanym woluminie, który może być macierzą RAID-1 lub pojedynczym dyskiem fizycznym. Aby to zrobić, możesz użyć niedrogiego dysku SSD, SATA / NL SAS HDD lub dysku logicznego, na którym znajduje się system operacyjny serwera i pliki użytkownika, i który jest częścią grupy RAID.

Przechowywanie danych 1C musi być zoptymalizowane w przypadku zwirtualizowanej struktury IT. W takim przypadku serwer SQL musi być zainstalowany na serwerze fizycznym, nie powinien być instalowany jako maszyna wirtualna. Pozwala to wygrać 15-35% wydajności podsystemu dyskowego. Dokładna liczba będzie zależeć od wielu parametrów, a mianowicie od narzędzi do wirtualizacji, charakterystyk sprzętu, sposobów podłączania wolumenu, używanych sterowników itp.

Jeśli środowisko serwera SQL jest zwirtualizowane, aby połączyć woluminy z plikami indeksu, plikami TempDB i tabelami bazy danych na maszynę wirtualną, należy użyć trybu dostępu wyłącznego za pośrednictwem dostępu bezpośredniego.

Kompromis między niezawodnością a wydajnością

Jeśli 1C zwalnia, najbardziej logicznym działaniem jest zwiększenie wydajności. Jednocześnie kwestia odporności jest zawsze bliska kwestii wydajności. Mówiąc najprościej, moc musi być poparta niezawodnością, a często istnieje kompromis między tymi dwoma parametrami.

Oczywiste jest, że lepiej nie wprowadzać do sytuacji, w których trzeba przywrócić 1C - łatwiej jest wcześniej zadbać o odporność na błędy serwera. Z drugiej strony może to wymagać dodatkowych kosztów, które są szczególnie trudne, jeśli trzeba pracować z ciągłymi procesami produkcyjnymi.

Wybór między wydajnością a niezawodnością Użytkownicy 1C często decydują w różnych płaszczyznach. Jeśli 1C zawiesza się podczas ładowania, drukowania, przetwarzania procesów, problem z wydajnością rozwiązuje się przez optymalizację sprzętu serwera. Odporność na błędy zapewnia organizacja procesów. Ponadto w przypadkach, w których aplikacje są umiarkowanie krytyczne, głównym aspektem niezawodności jest nie tyle ochrona serwerów, co skrócenie przestojów całej infrastruktury do minimum. Tymczasem ochrona serwera jest po prostu niezbędna i lepiej się nią zająć wcześniej niż ręcznie odzyskać utracone dane.

Z reguły następujące zabezpieczenia sprzętowe są używane do ochrony serwerów.

1. Instalacja UPS - fizyczna ochrona serwera przed zanikiem zasilania.
2. Wykorzystanie redundantnych serwerów zasilania.
3. Korzystanie z koszy na dyski typu hot-swap.
4. Wykorzystanie macierzy RAID z gorącą kopią zapasową jako części podsystemu dyskowego.

Wszystkie te środki są skuteczne i konieczne, ale nie rozwiązują problemu tworzenia kopii zapasowych danych. Backup 1C powinien być wykonywany zgodnie z planem, aby w krytycznej sytuacji większość bazy danych (z wyjątkiem ostatnich zmian) mogła zostać szybko przywrócona. Zaleca się wykonywanie kopii zapasowej 1C dziennie (na przykład w nocy), rezerwując bazę danych i plik operacyjny zawierający pełny dziennik SQL.

Uważa się, że w średnich i małych przedsiębiorstwach dopuszczalny czas przestoju centralnego systemu 1C wynosi 1-4 godziny, a wypadki powinny mieć miejsce nie więcej niż 1 lub 2 razy w miesiącu. Jeśli jesteś gotowy do wcześniejszego powrotu do zdrowia, rezerwa czasu jest wystarczająco duża.

Aby szybko zrestartować komputer, potrzebujesz obrazów wszystkich serwerów fizycznych i wirtualnych w maszynie wirtualnej, znajdujących się na oddzielnym woluminie. Umożliwi to szybkie przywrócenie infrastruktury na serwerze zapasowym. Kopia zapasowa Pełny dziennik SQL powinien być wykonywany codziennie, co tydzień i po zakończeniu okresu. Kopia zapasowa plików musi być wykonana na innym urządzeniu fizycznym. Jeśli do dyspozycji przedsiębiorstwa jest sprzęt zastępczy, ponowne uruchomienie może nastąpić w ciągu zaledwie 1-2 godzin. Warto zauważyć, że w przypadkach, gdy konieczne jest zapewnienie ciągłej pracy w trybie 24 * 7, zadanie jest znacznie bardziej skomplikowane: będzie wymagało opracowania odpowiedniej architektury, wyboru sprzętu, który ma minimum potencjalnych punktów awarii, zastosowania pełnoprawnych technologii klastrowania.

Idź