Przekroczono maksymalne zużycie pamięci na połączenie. Przeniesienie bazy danych TEPDB na inny, większy dysk

teraz trochę więcej szczegółów:

Klaster 1C 8.3

Przede wszystkim po zainstalowaniu klastra 1C konieczne było utworzenie przepływów pracy. Jak się okazało, procesy klastrowe zaczęto tworzyć automatycznie w zależności od obciążenia bazy danych.

Testowe uruchomienie zadań w tle głównej bazy danych spowodowało, że klaster 1C nieustannie przeciążał rphost.exe, a dodatkowy rphost.exe nie chciał zostać utworzony. Po przejrzeniu ustawień wszystko stało się jasne.

Maksymalna pamięć przepływu pracy to ilość pamięci, jaką procesy robocze mogą wspólnie wykorzystywać. Należy zachować szczególną ostrożność podczas ustawiania parametru mierzonego w bajtach. Jeśli ustawisz niewłaściwą wartość (niewystarczającą do normalnej pracy użytkownika), użytkownicy otrzymają błąd „Za mało wolnej pamięci na serwerze 1C”. Ten błąd może również wystąpić, gdy skończy się limit pamięci na serwerze 1C.

Bezpieczne zużycie pamięci na połączenie- pozwala kontrolować zużycie pamięci podczas połączenia z serwerem, mierzone w bajtach. Jeśli połączenie zużywa więcej pamięci niż oczekiwano, zostanie ono zakończone w klastrze 1C bez ponownego uruchamiania procesu roboczego (rphost.exe). W związku z tym „przegrany”, który wykonał połączenie z serwerem, utraci sesję z bazą danych 1C bez wpływu na pracę innych użytkowników.

w jednym GB - 1073741824 bajtów, zatem w 2 GB - 2147483648 bajtów

Ilość pamięci na procesy robocze, do której serwer jest uważany za produktywny - w przypadku przekroczenia tego parametru serwer w klastrze 1C przestanie akceptować nowe połączenia.

Liczba zabezpieczeń informacji na proces- pozwala wyodrębnić bazy informacyjne dla procesów pracy. Domyślnie bieżący klaster 1C był ustawiony na „8”, ale w ciągu kilku godzin pracy serwer stał się bardzo niestabilny, sesje użytkowników zawiesiły się. Po wyizolowaniu każdej bazy danych (wartość - „1”) problemy zniknęły.

Liczba połączeń na proces- wartość domyślna to „128”. Ponieważ aktualna baza danych zawiera bardzo duże obciążenie zadaniami w tle (obliczenia logistyczne, analiza cenników, analiza konkurencji itp.), zdecydowano się zmniejszyć tę liczbę do „25”.

Ustawienia samego klastra 1C nieznacznie się zmieniły:

Poziom tolerancji błędów- jest to liczba działających serwerów, które mogą ulec awarii w tym samym czasie i nie będzie to prowadzić do nieprawidłowego zakończenia pracy użytkowników. Usługi tworzenia kopii zapasowych uruchamiane są automatycznie w ilości niezbędnej do zapewnienia określonej odporności na awarie. W czasie rzeczywistym usługa aktywna jest replikowana do usług zapasowych.

Tryb udostępniania obciążenia- istnieją dwie opcje parametru: „Priorytet według wydajności” - zużywa się więcej pamięci serwera i wydajność jest wyższa, „Priorytet według pamięci” - klaster 1C oszczędza pamięć serwera.

Serwer 8.3 charakteryzuje się na nowo przeprojektowanym kodem wewnętrznym, choć „z zewnątrz” może się wydawać, że jest to nieco zmodyfikowany kod 8.2.

Serwer stał się bardziej „autokonfigurowalny”; niektóre parametry, takie jak liczba procesów roboczych, nie są już tworzone ręcznie, ale są obliczane na podstawie opisów wymagań zadań odporności na awarie i niezawodności.

Zmniejsza to prawdopodobieństwo błędnej konfiguracji serwera i obniża wymagania kwalifikacyjne dla administratorów.

Opracowano mechanizm równoważenia obciążenia, który można wykorzystać albo do zwiększenia wydajności systemu jako całości, albo do wykorzystania nowego trybu „oszczędzania pamięci”, który pozwala na pracę „z ograniczoną pamięcią” w przypadkach, gdy konfiguracja użyte „lubi pożerać pamięć”.

O stabilności pracy przy wykorzystaniu dużej ilości pamięci zadecydują nowe parametry serwera produkcyjnego.

Szczególnie interesujący jest parametr „bezpieczne zużycie pamięci na połączenie”. Dla tych, którzy nie mają pojęcia, co to jest, lepiej nie trenować w sposób „produktywny”. Parametr „Maksymalny rozmiar pamięci procesów roboczych” pozwala w przypadku „przepełnienia” nie zawieszać całego procesu roboczego, a tylko jedną sesję „z przegranym”. „Ilość działającej pamięci procesu, do której serwer jest uważany za produktywny” pozwala blokować nowe połączenia po przekroczeniu tego progu pamięci.

Zalecam izolowanie procesów pracy według bazy informacji, np. określając parametr „Liczba zabezpieczeń informacji na proces = 1”. W przypadku kilku mocno obciążonych baz danych zmniejszy to wzajemny wpływ zarówno pod względem niezawodności, jak i wydajności.

Osobny wkład w stabilność systemu ma „wydawanie” licencji/kluczy. W wersji 8.3 stało się możliwe użycie „menedżera licencji oprogramowania”, przypominającego menedżera „aladin”. Celem jest możliwość umieszczenia klucza na osobnej maszynie.

Jest ona zaimplementowana jako kolejna „usługa” w menedżerze klastrów. Można skorzystać np. z „darmowego” laptopa. Dodaj go do klastra 1C 8.3, utwórz na nim osobnego menedżera z usługą „usługi licencjonowania”. Możesz włożyć klucz sprzętowy do laptopa lub aktywować licencje na oprogramowanie.

Największe zainteresowanie programistów powinny wzbudzić „Wymagania dotyczące przypisania funkcjonalności”.

Wymagania dla przypisanej funkcjonalności 1c

Tak więc na laptopie z kluczem bezpieczeństwa, aby nie uruchamiać użytkowników na serwerze klastrowym, należy dodać „wymagania” dla obiektu wymagań „Połączenie klienta z bezpieczeństwem informacji” - „Nie przypisuj”, tj. uniemożliwiaj procesom roboczym na tym serwerze przetwarzanie połączeń klientów.

Jeszcze bardziej interesująca jest możliwość uruchamiania „tylko zadań w tle” na serwerze produkcyjnym klastra bez sesji użytkowników. W ten sposób możesz przenieść bardzo obciążone zadania (kod) na oddzielną maszynę. Ponadto na jednym komputerze można uruchomić jedno zadanie w tle „zamknięcie miesiąca” z wykorzystaniem „Wartości dodatkowego parametru” na drugim komputerze, a zadanie w tle „Aktualizacja indeksu pełnotekstowego” na drugim. Wyjaśnienie następuje poprzez wskazanie „Wartość dodatkowego parametru” dodatkowy parametr”. Na przykład, jeśli jako wartość określisz BackgroundJob.CommonModule, możesz ograniczyć pracę serwera roboczego w klastrze tylko do zadań w tle z dowolną zawartością. Wartość tłaJob.CommonModule.<Имя модуля>.<Имя метода>- wskaże konkretny kod.

Klaster 1C 8.2

Sesje umożliwiają równoważenie obciążenia i odporność na awarie w zarządzanej aplikacji.

Menedżer klastrów stał się teraz bardziej złożony. Niektóre funkcje można teraz wydzielić do osobnego procesu, a nawet umieścić na innym działającym serwerze w klastrze. Pozwala to zrównoważyć obciążenie serwera.

Odporność na awarie serwera 8.2 jest osiągnięta poprzez:

  • Zapamiętywanie informacji o sesji użytkownika.
  • Użytkownik nie jest już przywiązany do przepływu pracy.
  • Rezerwacja procesów pracy w klastrze.
  • Powinno istnieć kilka procesów roboczych, w tym procesy redundantne
  • Rezerwacja klastra.

Wskazany zostanie zapasowy klaster, który po podłączeniu zostanie wyświetlony w wierszu połączenia

Dzięki temu możesz zapewnić ciągłość pracy!

Jeżeli fizyczne połączenie klienta z klastrem zostanie zerwane (sprzątaczka wyciągnęła kabel, wyłączono zasilanie urządzeń sieciowych, był problem z dostawcą), nie ma potrzeby ponownego łączenia się z bazą danych i uruchamiania wszystkiego cała praca od nowa. Po przywróceniu połączenia fizycznego użytkownik może kontynuować pracę od momentu, w którym została przerwana.

Jeżeli wymagana jest konserwacja komputerów klastrowych, można je wyłączyć w trakcie pracy, nie utrudniając użytkownikom pracy z bazą informacji.

Jeśli którykolwiek serwer w klastrze ulegnie awarii, praca użytkownika nie zostanie zatrzymana; zostanie automatycznie przeniesiona do klastra zapasowego i/lub procesów pracy z kopią zapasową. Dla użytkowników takie przejście będzie niewidoczne.

Jeśli jeden z procesów roboczych klastra ulegnie awarii, podłączeni do niego użytkownicy zostaną automatycznie przeniesieni do innych lub zapasowych procesów roboczych. Takie przejście będzie również niewidoczne dla użytkowników.

Terminy, pojęcia

Dlaczego potrzebujesz serwera 1C?

Termin „klaster serwerów” odnosi się do kilku komputerów (serwerów) wykonujących wspólne zadanie.

Zadania rozwiązywane przez klaster serwerów 1C:Enterprise 8 pokazano na poniższym rysunku.

Różnica między 8.1 a 8.2

Klaster 1C 8.1

Klaster serwerów 1C:Enterprise 8.1 jest realizacją idei rozkładu obciążenia na serwerach obsługujących żądania klientów. Mechanizm ten rozkłada obciążenie zasobów obliczeniowych w obrębie jednego lub kilku serwerów („Serwery Robocze”), zapewniając w ten sposób skalowanie aplikacji. Klaster serwerów powiela kod obsługujący połączenia klientów. Zduplikowany kod wykonywalny klastra nosi nazwę „Proces roboczy” (rphost). Podczas instalowania klastra tworzony jest tylko jeden proces roboczy.
Kilka procesów roboczych na jednym serwerze umożliwia efektywne wykorzystanie ilości pamięci RAM i zasobów procesora do realizacji żądań, a także połączenie sesji klienta z innym procesem roboczym w przypadku „awarii bieżącego”.
Program Server Agent (ragent) jest odpowiedzialny za zrozumienie tego, co dzieje się na konkretnym serwerze. Zatrzymanie agenta serwera spowoduje, że serwer będzie niedostępny dla klastra. Agent przechowuje swoje informacje w pliku srvribrg.lst.
Informacje o bazach danych pracy i związanych z nimi procesach pracy są własnością „Menedżera serwera” (rmngr). Przechowuje te informacje w pliku 1CV8Reg.lst. Zatrzymanie menedżera serwera może spowodować ponowne uruchomienie aplikacji klienckich, jeśli menedżer uruchomi się ponownie pomyślnie, lub całkowite zatrzymanie działających serwerów w całym klastrze.
1C:Enterprise 8.1 umożliwia utworzenie kilku niezależnych klastrów na jednym serwerze. Każdy z nich identyfikowany jest w sieci poprzez unikalny „port IP” oraz unikalny numer w plikach usług. Pierwszy klaster domyślnie otrzymuje port 1541.
Przystawka Enterprise Servers służy do zarządzania klastrem.
Z serwerami można łączyć się według nazwy serwera lub adresu IP.

Agent serwera

Agent serwera „wie” o wszystkich klastrach działających na serwerze. Informacje te przechowywane są w pliku srvribrg.lst zawierającym listę klastrów i listę administratorów. Główny port agenta to 1540. Na każdym serwerze Roboczym może zostać uruchomiony tylko jeden agent obsługujący wszystkie możliwe klastry na tym serwerze.
Aby uzyskać bardziej szczegółowe informacje wizualnie, użyj narzędzia Process Explorer (opracowanego przez Sysinternals). Program pozwala głębiej zajrzeć do wszelkich uruchomionych procesów, w tym do klastra serwerów 1C:Enterprise 8.1.

Menedżer Klastra

Za funkcjonowanie klastra odpowiedzialny jest menadżer klastra. Każdy klaster ma swojego własnego Menedżera. Menedżer przechowuje informacje o klastrze w pliku 1CV8Reg.lst (rejestr klastra). Każdy menedżer klastra ma także swój własny port na serwerze roboczym. Dla pierwszego klastra domyślny port menedżera to 1541. To właśnie ten port jest wyświetlany w przystawce 1C:Enterprise Servers w gałęzi Clusters, identyfikując klaster.
Menedżer otrzymuje żądania od części klienta 1C:Enterprise 8.1 i podejmuje decyzję, któremu Workflow przekazać to żądanie usługi.

Menedżer wykorzystuje port usług do interakcji z procesami roboczymi.

Proces pracy

Proces Pracy jest odpowiedzialny za „pracę z klientami”. Można powiedzieć, że w poprzedniej wersji 1C:Enterprise 8.0 był tylko jeden „Przepływ pracy”.
W klastrze 1C:Enterprise 8.1 może znajdować się kilka procesów roboczych. Menedżer serwera decyduje, który proces roboczy będzie obsługiwał połączenie klienta. W przypadku połączeń klienckich procesom roboczym domyślnie przydzielany jest zakres portów IP od 1560 do 1591. Ponadto każdemu procesowi roboczemu przypisany jest port serwisowy umożliwiający komunikację z menedżerem klastra. Każdy proces roboczy zużywa do 2 GB pamięci RAM w 32-bitowym systemie operacyjnym. W 64-bitowym systemie operacyjnym ograniczenie wynika z fizycznej ilości pamięci RAM

Klaster 1C 8.2

Klaster serwerów 1C:Enterprise 8.2 – dalszy rozwój technologii serwerowych 8.2.

Serwer może pracować „jak 8.1”, czyli tzw. pozostaje kompatybilny z poprzednimi technologiami.

A dodatkowo wdrożono nowe podejście do działania serwera. Teraz zamiast procesów ważną rolę odgrywają sesje.

Sesje umożliwiają równoważenie obciążenia i odporność na awarie w zarządzanej aplikacji.

Menedżer Klastra

Menedżer klastrów stał się teraz bardziej złożony. Niektóre funkcje można teraz wydzielić do osobnego procesu, a nawet umieścić na innym działającym serwerze w klastrze. Pozwala to zrównoważyć obciążenie serwera.

Odporność na awarie serwera 8.2 jest osiągnięta poprzez:

  • Zapamiętywanie informacji o sesji użytkownika.
    • Użytkownik nie jest już przywiązany do przepływu pracy.
  • Rezerwacja procesów pracy w klastrze.
    • Powinno istnieć kilka procesów roboczych, w tym procesy redundantne
  • Rezerwacja klastra.
    • Wskazany zostanie zapasowy klaster, który po podłączeniu zostanie wyświetlony w wierszu połączenia

Pozwala to na ciągłość działania:

Jeżeli fizyczne połączenie klienta z klastrem zostanie zerwane (sprzątaczka wyciągnęła kabel, wyłączono zasilanie urządzeń sieciowych, był problem z dostawcą), nie ma potrzeby ponownego łączenia się z bazą danych i uruchamiania wszystkiego cała praca od nowa. Po przywróceniu połączenia fizycznego użytkownik może kontynuować pracę od momentu, w którym została przerwana.

Jeżeli wymagana jest konserwacja komputerów klastrowych, można je wyłączyć w trakcie pracy, nie utrudniając użytkownikom pracy z bazą informacji.

Jeśli którykolwiek serwer w klastrze ulegnie awarii, praca użytkownika nie zostanie zatrzymana; zostanie automatycznie przeniesiona do klastra zapasowego i/lub procesów pracy z kopią zapasową. Dla użytkowników takie przejście będzie niewidoczne.

Jeśli jeden z procesów roboczych klastra ulegnie awarii, podłączeni do niego użytkownicy zostaną automatycznie przeniesieni do innych lub zapasowych procesów roboczych. Takie przejście będzie również niewidoczne dla użytkowników.

Klaster 1C 8.3

Serwer 8.3 charakteryzuje się na nowo przeprojektowanym kodem wewnętrznym, choć „z zewnątrz” może się wydawać, że jest to nieco zmodyfikowany kod 8.2.

Serwer stał się bardziej „autokonfigurowalny”; niektóre parametry, takie jak liczba procesów roboczych, nie są już tworzone ręcznie, ale są obliczane na podstawie opisów wymagań zadań odporności na awarie i niezawodności.

Opracowano mechanizm równoważenia obciążenia, który można wykorzystać albo do zwiększenia wydajności systemu jako całości, albo do wykorzystania nowego trybu „oszczędzania pamięci”, który pozwala na pracę „z ograniczoną pamięcią” w przypadkach, gdy konfiguracja użyte „lubi pożerać pamięć”.

O stabilności pracy przy wykorzystaniu dużej ilości pamięci zadecydują nowe parametry serwera produkcyjnego.

Szczególnie interesujący jest parametr „bezpieczne zużycie pamięci na połączenie”. Dla tych, którzy nie mają pojęcia, co to jest, lepiej nie trenować w sposób „produktywny”. Parametr „Maksymalny rozmiar pamięci procesów roboczych” pozwala w przypadku „przepełnienia” nie zawieszać całego procesu roboczego, a tylko jedną sesję „z przegranym”. „Ilość działającej pamięci procesu, do której serwer jest uważany za produktywny” pozwala blokować nowe połączenia po przekroczeniu tego progu pamięci.

Zalecam izolowanie procesów pracy według bazy informacji, np. określając parametr „Liczba zabezpieczeń informacji na proces = 1”. W przypadku kilku mocno obciążonych baz danych zmniejszy to wzajemny wpływ zarówno pod względem niezawodności, jak i wydajności.

Osobny wkład w stabilność systemu ma „wydawanie” licencji/kluczy. W wersji 8.3 stało się możliwe użycie „menedżera licencji oprogramowania”, przypominającego menedżera „aladin”. Celem jest możliwość umieszczenia klucza na osobnej maszynie.

Jest ona zaimplementowana jako kolejna „usługa” w menedżerze klastrów. Można skorzystać np. z „darmowego” laptopa. Dodaj go do klastra 1C 8.3, utwórz na nim osobnego menedżera z usługą „usługi licencjonowania”. Możesz włożyć klucz sprzętowy do laptopa lub aktywować licencje na oprogramowanie.

Największe zainteresowanie programistów powinny wzbudzić „Wymagania dotyczące przypisania funkcjonalności”.

Tak więc na laptopie z kluczem bezpieczeństwa, aby nie uruchamiać użytkowników na serwerze klastrowym, należy dodać „wymagania” dla obiektu wymagań „Połączenie klienta z bezpieczeństwem informacji” - „Nie przypisuj”, tj. uniemożliwiaj procesom roboczym na tym serwerze przetwarzanie połączeń klientów.

Jeszcze bardziej interesująca jest możliwość uruchamiania „tylko zadań w tle” na serwerze produkcyjnym klastra bez sesji użytkowników. W ten sposób możesz przenieść bardzo obciążone zadania (kod) na oddzielną maszynę. Ponadto na jednym komputerze można uruchomić jedno zadanie w tle „zamknięcie miesiąca” z wykorzystaniem „Wartości dodatkowego parametru” na drugim komputerze, a zadanie w tle „Aktualizacja indeksu pełnotekstowego” na drugim. Wyjaśnienie następuje poprzez wskazanie „Wartość dodatkowego parametru” dodatkowy parametr”. Na przykład, jeśli jako wartość określisz BackgroundJob.CommonModule, możesz ograniczyć pracę serwera roboczego w klastrze tylko do zadań w tle z dowolną zawartością. Wartość tłaJob.CommonModule.<Имя модуля>.<Имя метода>- wskaże konkretny kod.

Rozwiązywanie ewentualnych problemów z instalacją

Instalując część serwerową 1C:Enterprise 8.1, możesz utworzyć nowego użytkownika lub wybrać istniejące konto.

W przypadku wybrania istniejącego konta należy podać prawidłowe hasło i potwierdzenie, w przeciwnym razie dalsze uruchomienie po stronie serwera zakończy się błędem.
Po pierwszym uruchomieniu agenta klastra tworzony jest klaster domyślny.
Klaster domyślny ma następujące cechy:
· numer portu – 1541;
· Zakres portów IP – 1560:1591;
· obsługa wielu przepływów pracy – wyłączona;
· jeden proces roboczy, numer portu ustawiany jest z określonego zakresu.
Jeśli przy pierwszym uruchomieniu Agenta klastra wystąpią jakiekolwiek problemy, klaster domyślny może nie zostać utworzony. Przejawia się to tym, że gdy uruchamia się agent serwera (ragent), to on się uruchamia, ale nie uruchamia innych procesów klastrowych (rmngr, rphost). Lista klastrów srvribrg.lst wygląda następująco:
{
{0},
W takim przypadku możesz zatrzymać proces ragentowy, usunąć listę klastrów (srvribrg.lst) i ponownie uruchomić ragent.

Sprawdź zgodność portów określonych w parametrze portu w wierszu poleceń służącym do uruchamiania usługi agenta serwera z portami określonymi w centralnym oknie dialogowym parametrów serwera w konsoli klastra:

— Zatrzymaj usługę agenta serwera 1C:Enterprise 8.1.

Jeśli Agent serwera działa jako aplikacja, można go zatrzymać, naciskając kombinację klawiszy Ctrl+C.
- Upewnij się w Menedżerze zadań, że wszystkie procesy ragent, rmngr, rphost zostały zakończone. Jeśli to konieczne, uzupełnij je za pomocą Menedżera zadań.

— Otwórz właściwości usługi agenta serwera 1C:Enterprise 8.1.

- Zwróć uwagę na wiersz „Plik wykonywalny” (Ścieżka do pliku wykonywalnego). Zawiera parametr -d, po którym następuje katalog danych klastra. Wszystkie pliki związane z klastrem znajdują się w tym katalogu.
- Usuń całą zawartość tego katalogu.
— Uruchom usługę agenta serwera 1C:Enterprise 8.1.
- Upewnij się w Menedżerze zadań, że wszystkie procesy ragent, rmngr, rphost zostały uruchomione.
— Uruchom konsolę klastra i zarejestruj w niej serwer centralny. Konsola powinna połączyć się z serwerem centralnym i wyświetlić jeden domyślnie utworzony klaster.
Możliwe problemy związane z awarią Klastra Serwerów obejmują problemy z kluczami bezpieczeństwa, uprawnieniami konta usługi i nieprawidłowymi parametrami startowymi.

  1. Klucz zabezpieczający serwer jest instalowany LOKALNIE na każdym serwerze w przedsiębiorstwie
  2. Nie ustawiaj konta usługi z pustym hasłem
  3. W przypadku wielu klastrów używane porty nie powinny się nakładać

Należy pamiętać, że podczas procesu instalacji platformy 1C:Enterprise 8.1 mogą zostać wyświetlone komunikaty o błędach. Poniżej wymieniono najbardziej prawdopodobne komunikaty. Wskazano przyczyny, które spowodowały pojawienie się komunikatów oraz kroki mające na celu ich wyeliminowanie.

Błąd 1069: Usługa nie działa z powodu błędu logowania

Problem jest związany z uprawnieniami konta do działania jako usługa systemowa. Otwórz narzędzie Zasady zabezpieczeń lokalnych i dodaj użytkownika (w imieniu którego uruchamiane są serwery pracy klastra) do zasad Logowanie jako usługa i Logowanie jako zadanie wsadowe.
Jeżeli dane zapisane w plikach serwisowych ulegną uszkodzeniu, uruchomienie Serwerów Produkcyjnych Klastra może się nie powieść. Upewnij się, że agent serwera 1C:Enterprise 8.1 jest uruchomiony (proces ragent w Menedżerze zadań).
Nie zapominaj, że audyt zdarzeń systemu Windows jest także narzędziem analitycznym. Aby to zrobić, sprawdź, czy w dzienniku zdarzeń systemu Windows nie pojawiają się jakieś „podejrzane” wiadomości.

Błąd 8007056B / 800708C5

Nowe hasło nie jest zgodne z zasadami dotyczącymi haseł. Hasło może być za krótkie lub używałeś go już niedawno.
Powód: hasło podane do konta w oknie dialogowym „Install 1C:Enterprise server” nie spełnia wymagań polityki bezpieczeństwa.
Rozwiązanie: Ustaw nowe hasło dla wybranego konta, które spełnia wymagania polityki bezpieczeństwa lub osłabia wymagania zastosowanej polityki bezpieczeństwa, tj. nie wymagaj „skomplikowanego” hasła, nie ograniczaj liczby znaków w haśle, nie sprawdzaj prób powtórzeń itp.

Błąd 1923: Brak uprawnień do instalacji przez usługę

Przyczyna: Błąd jest związany z uprawnieniami konta do instalacji aplikacji. Ten błąd jest typowy dla prób zainstalowania serwera na kontrolerze domeny, gdzie wymagane są zwiększone środki bezpieczeństwa.
Rozwiązanie: Nie używaj kontrolera domeny do hostowania serwera korporacyjnego ani nie rozluźniaj wymagań bezpieczeństwa i określ uprawnienia „Uruchom jako usługa” lub „Uruchom jako zadanie wsadowe” dla wybranego konta.

Błąd 80070056

Nie można zmienić Twojego hasła. Każde hasło musi być używane przez co najmniej x dni.
Przyczyna i rozwiązanie: Kolejny błąd występujący w przypadku naruszenia wymagań polityki bezpieczeństwa dotyczących używanych haseł. Rozwiązanie jest podobne do błędu 800708C5.

Gniazda systemu Windows — 11004(0x00002AFC)

1) Upewnij się, że na serwerze roboczym klastra w Menedżerze zadań działają:
Agent serwera (ragent.exe),
Menedżer klastrów (rmngr.exe),
Proces roboczy klastra (rphost.exe).
2) Aby sprawdzić rozpoznawanie nazw adresów IP, uruchom w wierszu poleceń:
nazwa komputera ping
W odpowiedzi systemu na polecenie interesuje nas ustalenie, czy zostanie określony adres IP.
3) Jeśli nazwa zostanie ustalona, ​​ale proces roboczy nadal nie zostanie znaleziony, upewnij się, że adres IP nazwy został określony<имя машины>I<имя машины>.<имя домена>nie są inaczej definiowane.

(Gniazda systemu Windows - 10054(0x00002746).

Zdalny host siłą zamknął połączenie.
Komunikat ten może zostać wyświetlony w przypadku ponownego uruchomienia serwera lub konieczności usunięcia procesu roboczego.
Ten błąd zwykle nie pojawia się po ponownym podłączeniu. Jeśli błąd będzie się powtarzał, należy zbadać przyczyny awarii serwerów produkcyjnych klastra.
Ten błąd może wystąpić, gdy proces roboczy osiągnie maksymalną pojemność pamięci w systemach 32-bitowych.
Innym przypadkiem jest próba połączenia od klienta z komunikatem o błędzie:

(Gniazda Windows — 10060(0x0000274C)

Próba nawiązania połączenia nie powiodła się, ponieważ... wymagana odpowiedź nie została otrzymana z innego komputera w wymaganym czasie lub już nawiązane połączenie zostało zerwane z powodu nieprawidłowej odpowiedzi z już podłączonego komputera.
Istotą tego błędu jest brak odpowiedzi w określonym czasie (timeout).
1) Upewnij się, że zapora sieciowa nie blokuje ruchu aplikacji. Wyłącz zaporę sieciową.
Aby to zrobić, uruchom polecenie w wierszu poleceń (polecenie jest dostępne począwszy od systemów Windows XP i Windows Server 2003; wcześniejsze wersje nie mają wbudowanej zapory sieciowej, ale można zainstalować oprogramowanie innych firm):
netszzapora sieciowaustawićtryb przeciwnywyłączyć
Jeśli polecenie się powiedzie, otrzymasz wiadomość:
OK.
Oprócz zapory sieciowej filtry sieciowe mogą blokować ruch. Domyślnie są wyłączone. Upewnij się jednak, że wygląda to tak:

  1. Otwórz folder Połączenia sieciowe.
  2. Kliknij prawym przyciskiem myszy połączenie sieciowe, które chcesz skonfigurować, i wybierz Nieruchomości.
  3. Na karcie Są pospolite(dla połączenia z siecią lokalną) lub na zakładce Internet(dla wszystkich pozostałych połączeń) wybierz Protokół internetowy (TCP/IP) i naciśnij przycisk Nieruchomości.
  4. Naciśnij przycisk Dodatkowo.
  5. Otwórz zakładkę Opcje, Wybierz opcję Filtrowanie TCP/IP i naciśnij przycisk Nieruchomości.
  6. Upewnij się, że pole wyboru Włącz filtrowanie TCP/IP (wszystkie karty) REMOVED.

2) Upewnij się, że zasoby procesora nie są obciążone w 100% (CPU%).
3) Zmierz aktywność sieciową interfejsów klienta i serwera. Obciążenie karty sieciowej nie powinno przekraczać 60%.

(Gniazda systemu Windows — 10061(0x0000274D)

Połączenie nie zostało nawiązane, ponieważ Komputer docelowy odrzucił żądanie połączenia.
Typową przyczyną tego błędu jest brak działającego agenta serwera. Uruchom serwer ręcznie lub zrestartuj serwer, aby uruchomić się automatycznie.

Odpowiedzi na pytania

Wieloplatformowy 1C

Instalacja serwera

P: Błąd podczas instalowania serwera 1c na MS Server 2008 R2 x64 Podczas instalowania serwera 1c za pomocą wiersza poleceń, na przykład ragent.exe -instsrvc -port 2040 -regport 2041 -range 2060:2091 -d „C:\Program Files\1cv82 \ (pobrany z dysku ITS), wiersz poleceń zapisuje komunikat: „Błąd! Błąd OpenSCManagera!” W tym przypadku usługa nie jest tworzona. Testowano 8.1.15.14 i 8.2.10.77

Odp.: Aby zainstalować z wiersza poleceń w systemie operacyjnym, w którym występuje UAC, musisz skorzystać z usługi RunAs, ponieważ Nawet jeśli użytkownik jest członkiem grupy Administratorzy, UAC blokuje działania zmieniające stan systemu.

Klucze zabezpieczające

P: Czy klucz ochronny dla serwera 8.2 pozwala mi uruchomić serwer 8.1?
Odpowiedź: Tak

P: Czy aby uruchomić serwer 1C, potrzebuję jakiegoś klucza hasp serwera? Lokalnie, czy nie będzie działać dla 5 użytkowników?

Odp.: tak, serwer potrzebuje własnego klucza, klucze użytkownika lokalnego i sieciowe nie będą działać. Więcej szczegółów w « « , slajd numer 30.

P: Załóżmy, że klaster serwerów 1C składa się z 3 serwerów fizycznych. ile kluczy bezpieczeństwa jest potrzebnych?

P: Dostępny jest serwer terminali i klucz na 5 licencji. Należy zakupić szóstą dodatkową licencję. licencja. Czy da się go zainstalować na serwerze obok klucza pod numerem 5? I czy wszystkich 6 użytkowników będzie pracować w sesjach terminalowych czy 5 - pod terminalem, a 1 w wersji plikowej?
Odpowiedź: Nie, nie zrobią tego. 6. licencja w postaci klucza lokalnego musi być wpięta do komputera użytkownika, a nie do terminala.

Aktualizacje serwera 1C

P: Kiedy zostanie wydana nowa wersja platformy 8.2.xxx, jaka będzie procedura aktualizacji serwerów i klientów?
O: Dystrybucje 8.2 instalują swoje pliki w różnych folderach (każda wersja ma swój własny folder), tj. teoretycznie nadal możliwe jest równoległe wywoływanie kilku wersji serwera.

Nie miałem żadnych problemów. Należy jednak uważnie monitorować porty zajmowane przez instancję serwera 1C. Nie powinno być żadnych skrzyżowań.

Konfigurowanie serwera 1C

P: W wersji 1C 8.1, jaki jest najlepszy sposób umieszczenia baz danych, jeśli jest ich kilka, w jednym klastrze lub utworzenia osobnego klastra dla każdej bazy danych? Odp.: Przy dużym wolumenie lub obciążeniu testowe bazy danych muszą być umieszczone w oddzielnych klastrach!

P: PYTANIE: Czy przepływ pracy w 1C:Enterprise 8.1 jest aplikacją jednowątkową czy wielowątkową? Te. czy jeden podłączony użytkownik może obciążyć wiele rdzeni? Z kilkoma? A co z przepływem pracy w 1C:Enterprise 8.2? Dziękuję.
O: 1Сv8.exe i rphost.exe w wersji 8.1 zużywały 1 rdzeń. Ponieważ w wersji 8.1 połączenie klienta jest ściśle powiązane z procesem roboczym, możemy warunkowo założyć, że przetwarzanie klienta 1C odbywa się w ramach jednego rdzenia. Wyjątkiem jest DBMS, który wykorzystuje jądra niezależnie od tego, jak działa serwer 1C.

W wersji 8.2 połączenia zostały zastąpione sesjami. Sesje mogą już działać w różnych procesach roboczych. Dlatego wywoływanie wersji 8.2 jednowątkowej prawdopodobnie nie jest poprawne. Klient 8.2 również wizualnie ładuje kilka rdzeni, więc:

Platforma 8.2 nie implementuje wszystkich możliwości systemu wielowątkowego, ale znacznie lepiej wykorzystuje możliwości sprzętowe w porównaniu do 8.1, także pod względem równoległości.

P: Czy konieczne jest posiadanie wielu procesów roboczych 1C:Enterprise 8.1 dla serwera bazy danych (MS SQL), aby załadować wiele rdzeni? (Należy zauważyć, że MS SQL zwykle „ładowuje” tylko jeden rdzeń, tj. „równoległe” przetwarzanie jednego żądania na kilku rdzeniach z reguły nie występuje.) Dziękuję.
Odp.: Nie ma potrzeby specjalnego zarządzania MS SQL; jest to dość samodostrajający się system, który wykorzystuje zasoby w miarę potrzeb. Możesz kontrolować równoległość wykonywania:

EXEC sys.sp_configure N’maks. stopień równoległości’, N’5′
IŚĆ
SKONFIGURUJ PONOWNIE Z NADPISANIEM
IŚĆ

Możesz utworzyć kilka procesów pracy na serwerze 1C, biorąc pod uwagę fakt, że jeden proces pracy nie zapewnia użytkownikom możliwości ponownego połączenia w przypadku awarii procesu pracy. Proces 2 (w wersji 8.2 lepiej jest zrobić „kopię zapasową”) rozwiązuje ten problem. Jednak dodanie trzeciego lub więcej procesów roboczych ma sens tylko wtedy, gdy pierwsze dwa procesy robocze są mocno obciążone (ponad 90%). Nie ma sensu niepotrzebnie mnożyć procesów pracy, może to pogorszyć produktywność.

O: W wersji 8.2 musi istnieć co najmniej 1 zapasowy proces roboczy.

Klaster pracy awaryjnej

P: Pytanie dotyczące włączenia redundancji dla klastrów 1s 8.2. Jeżeli nasz serwer uległ awarii (sprzątaczka wyciągnęła kabel) to nazwa sieci np. „serwer:2540” będzie niedostępna. Skąd klient, którego parametry połączenia mówią „serwer:2540”, wie, że musi połączyć się z klastrem zapasowym? skąd dostanie nazwę innego serwera? Co się stanie, jeśli w ciągu połączenia z bazą danych napiszesz klastry oddzielone przecinkami?
Odp.: Kilka klastrów jest połączonych w „grupę redundancji”. W tym celu w przystawce klastra dostępna jest „lista rezerwacji”.

Kiedy klient po raz pierwszy uzyskuje dostęp do klastra, otrzymuje listę klastrów zawartych w grupie redundancji.

Jeśli klient nigdy się z Tobą nie kontaktował, to w tym przypadku musisz ręcznie określić adresy wszystkich klastrów, np. burza:2541, potwór:2541.

Zsynchronizowane dane są wymieniane pomiędzy klastrami nadmiarowymi.

P: Co się stanie po przywróceniu głównego klastra? gdy użytkownicy przeszli na kopię zapasową.

Odpowiedź: Oni wracają. Podczas przełączania podczas synchronizacji tych klastrów mogą wystąpić przerwy.

Zadania w tle

P: Jak usunąć zadanie w tle działające na serwerach 1C:8.1 i 1C:8.2?

O: Możliwość anulowania rutynowego zadania działa tylko wtedy, gdy kod jest wykonywany w ramach wbudowanego języka 1C:Enterprise. Jeśli kod jest wykonywany w bibliotekach zewnętrznych, to takiego zadania nie można anulować, chyba że poprzez wymuszenie zakończenia przepływu pracy. Jeśli w procesie występuje blok StartTransaction() - CommitTransaction(), to jest to mało prawdopodobne. Inne zadania w tle można usunąć za pomocą konsoli zadań.

Procedury regulacyjne

P: Czy możliwe jest zniszczenie bazy podczas T&I?

Odp.: Nie znam takich przypadków, ale IMHO wszystko jest możliwe. Dlatego dobrym pomysłem byłoby wykonanie kopii zapasowej przed T&I.

P: Wiaczesław, z jakich powodów nie wykonujesz ponownego indeksowania za pomocą testów i korekt 1C?
O: Możliwości systemu DBMS lepiej nadają się do tych celów, ponieważ zasadniczo przebudowują również indeksy, ale nie wymagają wyłącznego przejęcia bazy danych.

Magazyn technologiczny

P: Dzień dobry. Pytanie z magazynu technologicznego: Muszę otrzymać kopie ekranów stacji roboczych w przypadku błędów 1C. Czy muszę w tym celu zakładać log technologiczny na stacjach roboczych, czy jest to tylko dla serwera?
Odpowiedź: Możesz skonfigurować otrzymywanie zrzutu ekranu tylko w przypadku upadku platformy, a nie w przypadku wystąpienia błędu. Jednak taka operacja nie ma zbyt dużej użyteczności, wystarczy zebrać sytuacje wyjątkowe za pomocą dziennika technologicznego. Jednocześnie większość błędów można zobaczyć za pomocą TZ po stronie serwera 1C. Wyjątkiem mogą być zdarzenia takie jak „błąd strumienia formatu” związany z nieaktualną pamięcią podręczną metadanych.

Problemy i błędy

P: Czy napotkałeś problem - zniknięcie ustawień raportów dla użytkowników podczas dynamicznej aktualizacji konfiguracji na platformie 8.2. Jakieś zalecenia, jak sobie z tym poradzić?
O: Problemy związane z aktualizacją dynamiczną są odzwierciedlone w „Serwery 1C: Enterprise 8.1 i 8.2 – z czym jeść”), slajd nr 60. Wyczyść pamięć podręczną. Być może w niektórych przypadkach konieczne jest zrozumienie, gdzie dokładnie przechowywane są ustawienia użytkownika. W razie potrzeby przechowuj dane binarne w rejestrze informacyjnym.

P: Pytanie powiązane, ponieważ... dotyczy to trybu plików: jakie błędy koryguje plik chdbfl.exe?
Odp.: To jest narzędzie do korekcji błędów struktury przechowywania danych. Może to mieć miejsce na przykład w przypadku pojawienia się komunikatu „Plik bazy danych jest uszkodzony.../1Cv8.1CD”. Te. naprawia uszkodzenie pliku bazy danych. Nie realizuje jednak funkcji T&I. Jeśli T&I nie działa pomyślnie, uruchamiam program chdbfl.exe.

P: Proszę, powiedz mi, czy napotkałeś taki problem. gdy w bazie danych znajduje się duża liczba użytkowników (ok. 40) przy przetwarzaniu dużych dokumentów np. odzwierciedlających PO w rej. Stanowi około 8000 linii. Komunikat o błędzie jest taki, że na serwerze korporacyjnym 1C nie ma wystarczającej ilości pamięci, a użytkownik, który zainicjował ten dokument, odpada. Dokument można następnie przetworzyć dopiero po ponownym uruchomieniu agenta serwera 1C.
Odp.: Wygląda na wycieki pamięci:

1. Uruchom ponownie serwer 1C, zwiększ liczbę procesów roboczych i zachowaj tylko tę jedną bazę danych w klastrze.

2. Pokonuj trzymanie porcjami, powiedz 1000 linii na raz. Używając TZ, śledź obiekty, które zajmują pamięć na początku operacji, ale nie zwalniaj pamięci po jej zakończeniu.

3. Zainstaluj wersję x64, zwiększ ilość RAM, przejdź na 8.2.

P: Pytanie dotyczące testowania i zarządzania. Czy możliwe jest uruchomienie „Sprawdzania integralności referencji” w oparciu o URDB z wyborem na podstawie przesłanych danych? (tj. w niektórych węzłach fizycznie nie ma obiektów, ale istnieją do nich łącza). Dziękuję!
Odpowiedź: Niestety, nie jest to jeszcze możliwe.

P: Dlaczego testowanie i naprawianie nie rozwiązuje wszystkich problemów na raz, czy trzeba to uruchamiać kilka razy?

Odp.: Tylko programiści mogą udzielić dokładnej odpowiedzi. Prowadzę T&I zgodnie z przepisami (cyklicznie), więc ta kwestia nie jest dla mnie specjalnie istotna. T&I należy wykonywać nie tylko raz, ale stale, jak na przykład „MOT samochodu”.

P: Czy istnieje różnica pomiędzy T&I 8.1 a 8.2?

O: W chwili pisania odpowiedzi i wydania wersji 8.2.10 nie widzę różnicy.

P: Czy konieczna jest reindeksacja w trakcie restrukturyzacji?
O: Nie ma potrzeby.

Inny

P: Szanowni Państwo, czy ktoś próbował wykonać kopię lustrzaną baz danych przy użyciu MSSql 2008?Czy jest to w ogóle możliwe?

P: Pytanie dotyczące wymuszania pamięci współdzielonej na serwerze 1s 8.2

O: Nie ma potrzeby niczego wymuszać, serwer to zrozumie.

P: W przypadku 1C:Enterprise 8.1 zauważono sytuacje, gdy na tym samym sprzęcie wersja serwera plików z „ciężkimi” operacjami i jednym użytkownikiem działa znacznie szybciej niż wersja klient-serwer, gdy wszystkie „łącza” (baza danych serwer, serwer 1C: Enterprise i klient) są zainstalowane na tym samym serwerze. Co więcej, podczas wykonywania tej „ciężkiej” operacji nie ma oczywistych przeciążeń sprzętu (obciążenie procesora, pamięci i dysków twardych jest minimalne). Oznacza to, że zasobów sprzętowych jest dużo, ale działają powoli. Na czym możemy „odpocząć”? Dziękuję.
O: Zaletą architektury klient-serwer z punktu widzenia wydajności jest możliwość przetwarzania żądań klientów o dane w trybie RÓWNOLEGŁYM. Te. Prędkość przepływu nie jest wskaźnikiem, na podstawie którego można wyciągać ogólne wnioski. Mechanizmy poprawiające współbieżność mogą nadal nieznacznie zmniejszać wydajność w ramach pojedynczego wątku.

Aby jednoznacznie znaleźć wąskie gardło w Twoim przypadku należy poznać obciążenie sprzętu serwerowego i porównać je w czasie z najdłuższymi operacjami w trybie klient-serwer. Często jest to nadmierny przepływ danych po stronie klienta. Te. Zamiast wykonywać operacje na serwerze 1C, dane z bazy danych są przesyłane przez serwer do klienta.

Szybkość w jednym wątku wersji klient-serwer dogoni jedynie wydajność wersji plikowej. Warto zmierzyć się z tym problemem, jeśli czas pracy w liczbach bezwzględnych mierzony jest w nie mniej niż minutach. Optymalizacja zapytań w ciągu 1-3 sekund jest wątpliwa.

P: O różnicy między terminalem Windows a cienkim klientem 1C.
O: Dopóki większość rozwiązań nie zostanie CAŁKOWICIE przetłumaczona na wersję 8.2, zdecydowanie trudno mówić o praktycznym porównaniu tych technologii.

Oczywiste jest, że cienki klient 1C powinien zużywać mniej ruchu i zapewniać możliwość pracy przez Internet. Jest to jednak coś, co nie zostało jeszcze wdrożone, a rozwiązania terminalowe są obecnie stosowane bardzo szeroko.

Dla konserwatywnych, pragmatycznych kierowników projektów konwersja 8.1 na 8.2 - rozwiązanie terminalowe. W przypadku małych projektów z niskim kosztem błędów i natychmiastową konfiguracją za pomocą zarządzanych formularzy i systemów kontroli dostępu, IMHO preferowany jest cienki klient.

P: Jak przeprowadzić testy obciążenia zbliżone do warunków rzeczywistych? W końcu nie możesz zmusić użytkowników, aby „coś kliknęli”.

Odp.: 1C: Centrum testowe z wyborem najtrudniejszych operacji, 100% reprodukcja nie jest konieczna, same kliknięcia nie są trudne, głównie przeprowadzanie i proszenie o raporty. Odbędzie się osobne webinarium na temat testowania. Opowiem Ci również bardziej szczegółowo.

05.04.2017 |

Klaster 1C 8.3

Przede wszystkim po zainstalowaniu klastra 1C konieczne było utworzenie przepływów pracy. Jak się okazało, procesy klastrowe zaczęto tworzyć automatycznie w zależności od obciążenia bazy danych.

Testowe uruchomienie zadań w tle głównej bazy danych spowodowało, że klaster 1C nieustannie przeciążał rphost.exe, a dodatkowy rphost.exe nie chciał zostać utworzony. Po przejrzeniu ustawień wszystko stało się jasne.

Maksymalna pamięć przepływu pracy to ilość pamięci, jaką procesy robocze mogą wspólnie wykorzystywać. Należy zachować szczególną ostrożność podczas ustawiania parametru mierzonego w bajtach. Jeśli ustawisz niewłaściwą wartość (niewystarczającą do normalnej pracy użytkownika), użytkownicy otrzymają błąd „Za mało wolnej pamięci na serwerze 1C”. Ten błąd może również wystąpić, gdy skończy się limit pamięci na serwerze 1C.

Bezpieczne zużycie pamięci na połączenie- pozwala kontrolować zużycie pamięci podczas połączenia z serwerem, mierzone w bajtach. Jeśli połączenie zużywa więcej pamięci niż oczekiwano, zostanie ono zakończone w klastrze 1C bez ponownego uruchamiania procesu roboczego (rphost.exe). W związku z tym „przegrany”, który wykonał połączenie z serwerem, utraci sesję z bazą danych 1C bez wpływu na pracę innych użytkowników.

w jednym GB - 1073741824 bajtów, zatem w 2 GB - 2147483648 bajtów

Ilość pamięci na procesy robocze, do której serwer jest uważany za produktywny - w przypadku przekroczenia tego parametru serwer w klastrze 1C przestanie akceptować nowe połączenia.

Liczba zabezpieczeń informacji na proces- pozwala wyodrębnić bazy informacyjne dla procesów pracy. Domyślnie bieżący klaster 1C był ustawiony na „8”, ale w ciągu kilku godzin pracy serwer stał się bardzo niestabilny, sesje użytkowników zawiesiły się. Po wyizolowaniu każdej bazy danych (wartość - „1”) problemy zniknęły.

Liczba połączeń na proces- wartość domyślna to „128”. Ponieważ aktualna baza danych zawiera bardzo duże obciążenie zadaniami w tle (obliczenia logistyczne, analiza cenników, analiza konkurencji itp.), zdecydowano się zmniejszyć tę liczbę do „25”.

Ustawienia samego klastra 1C nieznacznie się zmieniły:

Poziom tolerancji błędów- jest to liczba działających serwerów, które mogą ulec awarii w tym samym czasie i nie będzie to prowadzić do nieprawidłowego zakończenia pracy użytkowników. Usługi tworzenia kopii zapasowych uruchamiane są automatycznie w ilości niezbędnej do zapewnienia określonej odporności na awarie. W czasie rzeczywistym usługa aktywna jest replikowana do usług zapasowych.

Tryb udostępniania obciążenia- istnieją dwie opcje parametru: „Priorytet według wydajności” - zużywa się więcej pamięci serwera i wydajność jest wyższa, „Priorytet według pamięci” - klaster 1C oszczędza pamięć serwera.

Serwer 8.3 charakteryzuje się na nowo przeprojektowanym kodem wewnętrznym, choć „z zewnątrz” może się wydawać, że jest to nieco zmodyfikowany kod 8.2.

Serwer stał się bardziej „autokonfigurowalny”; niektóre parametry, takie jak liczba procesów roboczych, nie są już tworzone ręcznie, ale są obliczane na podstawie opisów wymagań zadań odporności na awarie i niezawodności.

Zmniejsza to prawdopodobieństwo błędnej konfiguracji serwera i obniża wymagania kwalifikacyjne dla administratorów.

Opracowano mechanizm równoważenia obciążenia, który można wykorzystać albo do zwiększenia wydajności systemu jako całości, albo do wykorzystania nowego trybu „oszczędzania pamięci”, który pozwala na pracę „z ograniczoną pamięcią” w przypadkach, gdy konfiguracja użyte „lubi pożerać pamięć”.

O stabilności pracy przy wykorzystaniu dużej ilości pamięci zadecydują nowe parametry serwera produkcyjnego.

Szczególnie interesujący jest parametr „bezpieczne zużycie pamięci na połączenie”. Dla tych, którzy nie mają pojęcia, co to jest, lepiej nie trenować w sposób „produktywny”. Parametr „Maksymalny rozmiar pamięci procesów roboczych” pozwala w przypadku „przepełnienia” nie zawieszać całego procesu roboczego, a tylko jedną sesję „z przegranym”. „Ilość działającej pamięci procesu, do której serwer jest uważany za produktywny” pozwala blokować nowe połączenia po przekroczeniu tego progu pamięci.

Zalecam izolowanie procesów pracy według bazy informacji, np. określając parametr „Liczba zabezpieczeń informacji na proces = 1”. W przypadku kilku mocno obciążonych baz danych zmniejszy to wzajemny wpływ zarówno pod względem niezawodności, jak i wydajności.

Osobny wkład w stabilność systemu ma „wydawanie” licencji/kluczy. W wersji 8.3 stało się możliwe użycie „menedżera licencji oprogramowania”, przypominającego menedżera „aladin”. Celem jest możliwość umieszczenia klucza na osobnej maszynie.

Jest ona zaimplementowana jako kolejna „usługa” w menedżerze klastrów. Można skorzystać np. z „darmowego” laptopa. Dodaj go do klastra 1C 8.3, utwórz na nim osobnego menedżera z usługą „usługi licencjonowania”. Możesz włożyć klucz sprzętowy do laptopa lub aktywować licencje na oprogramowanie.

Największe zainteresowanie programistów powinny wzbudzić „Wymagania dotyczące przypisania funkcjonalności”.

Wymagania dla przypisanej funkcjonalności 1c

Tak więc na laptopie z kluczem bezpieczeństwa, aby nie uruchamiać użytkowników na serwerze klastrowym, należy dodać „wymagania” dla obiektu wymagań „Połączenie klienta z bezpieczeństwem informacji” - „Nie przypisuj”, tj. uniemożliwiaj procesom roboczym na tym serwerze przetwarzanie połączeń klientów.

Jeszcze bardziej interesująca jest możliwość uruchamiania „tylko zadań w tle” na serwerze produkcyjnym klastra bez sesji użytkowników. W ten sposób możesz przenieść bardzo obciążone zadania (kod) na oddzielną maszynę. Ponadto na jednym komputerze można uruchomić jedno zadanie w tle „zamknięcie miesiąca” z wykorzystaniem „Wartości dodatkowego parametru” na drugim komputerze, a zadanie w tle „Aktualizacja indeksu pełnotekstowego” na drugim. Wyjaśnienie następuje poprzez wskazanie „Wartość dodatkowego parametru” dodatkowy parametr”. Na przykład, jeśli jako wartość określisz BackgroundJob.CommonModule, możesz ograniczyć pracę serwera roboczego w klastrze tylko do zadań w tle z dowolną zawartością. Wartość tłaJob.CommonModule.<Имя модуля>.<Имя метода>- wskaże konkretny kod.

Klaster 1C 8.2

Sesje umożliwiają równoważenie obciążenia i odporność na awarie w zarządzanej aplikacji.

Menedżer klastrów stał się teraz bardziej złożony. Niektóre funkcje można teraz wydzielić do osobnego procesu, a nawet umieścić na innym działającym serwerze w klastrze. Pozwala to zrównoważyć obciążenie serwera.

Odporność na awarie serwera 8.2 jest osiągnięta poprzez:

  • Zapamiętywanie informacji o sesji użytkownika.
  • Użytkownik nie jest już przywiązany do przepływu pracy.
  • Rezerwacja procesów pracy w klastrze.
  • Powinno istnieć kilka procesów roboczych, w tym procesy redundantne
  • Rezerwacja klastra.

Wskazany zostanie zapasowy klaster, który po podłączeniu zostanie wyświetlony w wierszu połączenia

Dzięki temu możesz zapewnić ciągłość pracy!

Jeżeli fizyczne połączenie klienta z klastrem zostanie zerwane (sprzątaczka wyciągnęła kabel, wyłączono zasilanie urządzeń sieciowych, był problem z dostawcą), nie ma potrzeby ponownego łączenia się z bazą danych i uruchamiania wszystkiego cała praca od nowa. Po przywróceniu połączenia fizycznego użytkownik może kontynuować pracę od momentu, w którym została przerwana.

Jeżeli wymagana jest konserwacja komputerów klastrowych, można je wyłączyć w trakcie pracy, nie utrudniając użytkownikom pracy z bazą informacji.

Jeśli którykolwiek serwer w klastrze ulegnie awarii, praca użytkownika nie zostanie zatrzymana; zostanie automatycznie przeniesiona do klastra zapasowego i/lub procesów pracy z kopią zapasową. Dla użytkowników takie przejście będzie niewidoczne.

Jeśli jeden z procesów roboczych klastra ulegnie awarii, podłączeni do niego użytkownicy zostaną automatycznie przeniesieni do innych lub zapasowych procesów roboczych. Takie przejście będzie również niewidoczne dla użytkowników.

Często na komputerze wraz z serwerem 1C:Enterprise działają inne usługi - serwer terminali, serwer SQL itp. W pewnym momencie serwer 1C:Enterprise, a raczej proces roboczy rphost, zużywa więcej pamięci niż planowano lub całą pamięć. Co prowadzi do spowolnienia innych usług i zombie serwera. Aby uniknąć takich sytuacji, należy skonfigurować automatyczne ponowne uruchamianie przepływów pracy serwera 1C:Enterprise

Rozwiązanie

1. Otwórz konsolę administracyjną serwerów 1C Enterprise;
2. Rozwiń drzewo serwerów centralnych o klastry i wybierz klaster, który nas interesuje. W tym przykładzie jest tylko jeden klaster;
3. Otwórz właściwości wybranego klastra i zobacz poniższy formularz

Właściwości klastra serwerów 1C:Enterprise 8.3

Spójrzmy na przykład pokazany na obrazku:

Interwał ponownego uruchomienia— czas, po którym proces rphost zostanie zmuszony do ponownego uruchomienia. Przed zakończeniem procesu uruchamiany jest nowy proces rphost, do którego przenoszone są wszystkie połączenia i dopiero wtedy kończy się stary proces. Nie będzie to miało żadnego wpływu na doświadczenia użytkownika. Odstęp jest podawany w sekundach, w przykładzie wskazane są 24 godziny.

Dozwolony rozmiar pamięci— ilość pamięci, w ramach której przepływ pracy może działać bez problemów. Wolumin jest podany w kilobajtach, w przykładzie wartość wynosi 20 gigabajtów (w rzeczywistości liczba jest za duża i trzeba zacząć od konkretnego systemu, ale średnia liczba to 4 GB). Gdy tylko pamięć zajmowana przez proces roboczy przekroczy określoną wartość, rozpoczyna się odliczanie.

Interwał przekroczenia dopuszczalnej ilości pamięci— po tym jak timer uruchomiony po przekroczeniu dopuszczalnej ilości pamięci odliczy zadany czas, zostanie uruchomiony nowy proces roboczy, do którego zostaną przeniesione wszystkie połączenia, stary proces zostanie oznaczony jako wyłączony. Odstęp jest podany w sekundach, w przykładzie podano 30 sekund.

Zatrzymaj wyłączone procesy po— czas, po którym obieg oznaczony jako wyłączony zostanie zatrzymany, jeżeli wartość wynosi 0, proces nie zostanie zakończony. Odstęp jest podany w sekundach, w przykładzie podano 60 sekund.

Po zastosowaniu ustawień nie trzeba ponownie uruchamiać usługi serwera, są one stosowane dynamicznie.

Całkowity

W ten sposób konfigurujemy automatyczny restart procesów pracy serwera 1C:Enterprise i uzyskujemy bardziej stabilny system; w przypadku wystąpienia wycieku pamięci praca określonej sesji zostanie przerwana.

Ponadto w niektórych sytuacjach możesz pobawić się ustawieniami i zapobiec możliwej awarii serwera w przypadku popełnienia błędów.

Przede wszystkim po zainstalowaniu klastra 1C konieczne było utworzenie przepływów pracy. Jak się okazało, procesy klastrowe zaczęto tworzyć automatycznie w zależności od obciążenia bazy danych.

Testowe uruchomienie zadań w tle głównej bazy danych spowodowało, że klaster 1C nieustannie przeciążał rphost.exe, a dodatkowy rphost.exe nie chciał zostać utworzony. Po przejrzeniu ustawień wszystko stało się jasne.

Maksymalna pamięć przepływu pracy to ilość pamięci, jaką procesy robocze mogą wspólnie wykorzystywać. Należy zachować szczególną ostrożność podczas ustawiania parametru mierzonego w bajtach. Jeśli ustawisz niewłaściwą wartość (niewystarczającą do normalnej pracy użytkownika), użytkownicy otrzymają błąd „Za mało wolnej pamięci na serwerze 1C”. Ten błąd może również wystąpić, gdy skończy się limit pamięci na serwerze 1C.

Bezpieczne zużycie pamięci na połączenie– pozwala kontrolować zużycie pamięci podczas połączenia z serwerem, mierzone w bajtach. Jeśli połączenie zużywa więcej pamięci niż oczekiwano, zostanie ono zakończone w klastrze 1C bez ponownego uruchamiania procesu roboczego (rphost.exe). W związku z tym „przegrany”, który wykonał połączenie z serwerem, utraci sesję z bazą danych 1C bez wpływu na pracę innych użytkowników.

w jednym GB – 1073741824 bajtów, zatem w 2 GB – 2147483648 bajtów

Ilość pamięci na procesy robocze, do której serwer jest uważany za produktywny - w przypadku przekroczenia tego parametru serwer w klastrze 1C przestanie akceptować nowe połączenia.

Liczba zabezpieczeń informacji na proces– pozwala wyodrębnić bazy informacyjne dla procesów pracy. Domyślnie bieżący klaster 1C był ustawiony na „ 8 „, ale w ciągu kilku godzin pracy serwer zachowywał się bardzo niestabilnie, sesje użytkowników zawieszały się. Po wyizolowaniu każdej bazy danych (wartość – „1”) problemy zniknęły.

Liczba połączeń na proces- domyślna wartość " 128 „. Ponieważ aktualna baza danych zawiera bardzo duże obciążenie zadaniami w tle (obliczenia logistyczne, analiza cenników, analiza konkurencji itp.), zdecydowano się zmniejszyć tę liczbę do „25”.

Ustawienia samego klastra 1C nieznacznie się zmieniły:

Poziom tolerancji błędów– jest to liczba działających serwerów, które mogą jednocześnie ulec awarii i nie będzie to prowadzić do nieprawidłowego zakończenia pracy użytkowników. Usługi tworzenia kopii zapasowych uruchamiane są automatycznie w ilości niezbędnej do zapewnienia określonej odporności na awarie. W czasie rzeczywistym usługa aktywna jest replikowana do usług zapasowych.

Tryb udostępniania obciążenia– dostępne są dwie opcje parametru: „Priorytet według wydajności” – zużywa się więcej pamięci serwera i wydajność jest wyższa, „Priorytet według pamięci” – klaster 1C oszczędza pamięć serwera.

Serwer 8.3 charakteryzuje się na nowo przeprojektowanym kodem wewnętrznym, choć „z zewnątrz” może się wydawać, że jest to nieco zmodyfikowany kod 8.2.

Serwer stał się bardziej „autokonfigurowalny”; niektóre parametry, takie jak liczba procesów roboczych, nie są już tworzone ręcznie, ale są obliczane na podstawie opisów wymagań zadań odporności na awarie i niezawodności.

Zmniejsza to prawdopodobieństwo błędnej konfiguracji serwera i obniża wymagania kwalifikacyjne dla administratorów.

Opracowano mechanizm równoważenia obciążenia, który można wykorzystać albo do zwiększenia wydajności systemu jako całości, albo do wykorzystania nowego trybu „oszczędzania pamięci”, który pozwala na pracę „z ograniczoną pamięcią” w przypadkach, gdy konfiguracja użyte „lubi pożerać pamięć”.

O stabilności pracy przy wykorzystaniu dużej ilości pamięci zadecydują nowe parametry serwera produkcyjnego.

Szczególnie interesujący jest parametr „bezpieczne zużycie pamięci na połączenie”. Dla tych, którzy nie mają pojęcia, co to jest, lepiej nie trenować w sposób „produktywny”. Parametr „Maksymalny rozmiar pamięci procesów roboczych” pozwala w przypadku „przepełnienia” nie zawieszać całego procesu roboczego, a tylko jedną sesję „z przegranym”. „Ilość działającej pamięci procesu, do której serwer jest uważany za produktywny” pozwala blokować nowe połączenia po przekroczeniu tego progu pamięci.

Zalecam izolowanie procesów pracy według bazy informacji, np. określając parametr „Liczba zabezpieczeń informacji na proces = 1”. W przypadku kilku mocno obciążonych baz danych zmniejszy to wzajemny wpływ zarówno pod względem niezawodności, jak i wydajności.

Osobny wkład w stabilność systemu ma „wydawanie” licencji/kluczy. W wersji 8.3 stało się możliwe użycie „menedżera licencji oprogramowania”, przypominającego menedżera „aladin”. Celem jest możliwość umieszczenia klucza na osobnej maszynie.

Jest ona zaimplementowana jako kolejna „usługa” w menedżerze klastrów. Można skorzystać np. z „darmowego” laptopa. Dodaj go do klastra 1C 8.3, utwórz na nim osobnego menedżera z usługą „usługi licencjonowania”. Możesz włożyć klucz sprzętowy do laptopa lub aktywować licencje na oprogramowanie.

Największe zainteresowanie programistów powinny wzbudzić „Wymagania dotyczące przypisania funkcjonalności”.

Wymagania dla przypisanej funkcjonalności 1c

Zatem na laptopie z kluczem bezpieczeństwa, aby nie uruchamiać użytkowników na serwerze klastrowym, należy dodać „wymagania” dla obiektu wymagania „Połączenie klienta z bezpieczeństwem informacji” – „Nie przypisuj”, tj. uniemożliwiaj procesom roboczym na tym serwerze przetwarzanie połączeń klientów.

Jeszcze bardziej interesująca jest możliwość uruchamiania „tylko zadań w tle” na serwerze produkcyjnym klastra bez sesji użytkowników. W ten sposób możesz przenieść bardzo obciążone zadania (kod) na oddzielną maszynę. Ponadto na jednym komputerze można uruchomić jedno zadanie w tle „zamknięcie miesiąca” z wykorzystaniem „Wartości dodatkowego parametru” na drugim komputerze, a zadanie w tle „Aktualizacja indeksu pełnotekstowego” na drugim. Wyjaśnienie następuje poprzez wskazanie „Wartość dodatkowego parametru” dodatkowy parametr”. Na przykład, jeśli jako wartość określisz BackgroundJob.CommonModule, możesz ograniczyć pracę serwera roboczego w klastrze tylko do zadań w tle z dowolną zawartością. Wartość tłaJob.CommonModule.<Имя модуля>.<Имя метода>– wskaże konkretny kod.