종종 다른 서비스가 1C:Enterprise 서버(터미널 서버, SQL 서버 등)와 함께 시스템에서 실행됩니다. 그리고 어느 시점에서 1C:Enterprise 서버 또는 오히려 rphost 작업자 프로세스는 계획보다 더 많은 메모리 또는 모든 메모리를 소모합니다. 이로 인해 서버의 다른 서비스와 좀비가 느려집니다. 이러한 상황을 방지하려면 1C:Enterprise 서버 워크플로의 자동 다시 시작을 구성해야 합니다.
해결책
1. 1C Enterprise 서버의 관리 콘솔을 엽니다.
2. 중앙 서버 트리를 클러스터로 확장하고 관심 있는 클러스터를 선택합니다. 이 예에는 클러스터가 하나만 있습니다.
3. 선택한 클러스터의 속성을 열고 다음 양식을 확인하세요.
1C:Enterprise 8.3 서버 클러스터의 속성
이미지에 표시된 예를 살펴보겠습니다.
재시작 간격— rphost 프로세스가 강제로 다시 시작되기까지의 시간입니다. 프로세스가 종료되기 전에 새로운 rphost 프로세스가 시작되어 모든 연결이 전송되고 그 후에야 이전 프로세스가 종료됩니다. 이는 어떤 식으로든 사용자 경험에 영향을 미치지 않습니다. 간격은 초 단위로 표시되며, 예에서는 24시간이 표시됩니다.
허용되는 메모리 크기— 작업 흐름이 문제 없이 작동할 수 있는 메모리 양. 볼륨은 킬로바이트 단위로 표시되며, 예에서 값은 20GB입니다(실제로 수치가 너무 커서 특정 시스템에서 시작해야 하지만 평균 수치는 4GB입니다). 작업 프로세스가 차지하는 메모리가 지정된 값을 초과하는 즉시 카운트다운이 시작됩니다.
허용되는 메모리 양을 초과하는 간격— 허용되는 메모리 양을 초과한 후 시작된 타이머가 지정된 시간을 카운트다운한 후 모든 연결이 전송되는 새 작업자 프로세스가 시작되고 이전 프로세스는 비활성화된 것으로 표시됩니다. 간격은 초 단위로 지정되며, 예에서는 30초가 표시됩니다.
다음 이후에 비활성화된 프로세스를 중지합니다.— 비활성화된 것으로 표시된 워크플로가 중지되기까지의 시간입니다. 값이 0이면 프로세스가 완료되지 않습니다. 간격은 초 단위로 지정되며, 예에서는 60초가 표시됩니다.
설정을 적용한 후에는 서버 서비스를 다시 시작할 필요가 없습니다. 설정은 동적으로 적용됩니다.
총
이것이 1C:Enterprise 서버 작업 프로세스의 자동 재시작을 설정하고 보다 안정적인 시스템을 확보하는 방법입니다. 메모리 누수가 발생하면 특정 세션의 작업이 종료됩니다.
또한 어떤 상황에서는 설정을 조작하여 실수로 발생할 수 있는 서버 충돌을 방지할 수 있습니다.
서버 8.3은 새롭게 재설계된 내부 코드가 특징이지만 "외부에서"는 약간 수정된 8.2처럼 보일 수 있습니다.
서버는 더욱 "자동 구성 가능"해졌습니다. 작업자 프로세스 수와 같은 일부 매개변수는 더 이상 수동으로 생성되지 않고 내결함성 및 안정성 작업 요구 사항에 대한 설명을 기반으로 계산됩니다.
시스템 전체의 성능을 높이거나 새로운 "메모리 절약" 모드를 사용하여 구성이 제한된 경우 "제한된 메모리로" 작업할 수 있는 로드 밸런싱 메커니즘이 개발되었습니다. "기억을 잡아먹는 걸 좋아해요"라는 말을 사용했어요.
대용량 메모리 사용 시 작동 안정성은 프로덕션 서버의 새로운 매개변수에 따라 결정됩니다.
"호출당 안전한 메모리 소비" 매개변수는 특히 흥미롭습니다. 그것이 무엇인지 거의 모르는 사람들에게는 "생산적인" 방식으로 훈련하지 않는 것이 좋습니다. "작업 프로세스의 최대 메모리 크기" 매개변수는 "오버플로"의 경우 전체 작업 프로세스를 중단시키지 않고 "패자"가 있는 하나의 세션만 중단하도록 허용합니다. "서버가 생산적인 것으로 간주되는 작업 프로세스용 메모리 양"을 사용하면 이 메모리 임계값을 초과하는 즉시 새 연결을 차단할 수 있습니다.
예를 들어 "프로세스당 정보 보안 수 = 1"이라는 매개변수를 지정하는 등 정보 기반별로 작업 프로세스를 격리하는 것이 좋습니다. 로드가 많은 여러 데이터베이스를 사용하면 안정성과 성능 측면에서 상호 영향이 줄어듭니다.
라이센스/키의 "지출"은 시스템 안정성에 대한 별도의 기여입니다. 8.3에서는 "알라딘" 관리자를 연상시키는 "소프트웨어 라이선스 관리자"를 사용하는 것이 가능해졌습니다. 목표는 키를 별도의 컴퓨터에 배치할 수 있는 것입니다.
이는 클러스터 관리자에서 또 다른 "서비스"로 구현됩니다. 예를 들어 "무료" 노트북을 사용할 수 있습니다. 1C 8.3 클러스터에 추가하고 "라이선스 서비스" 서비스를 사용하여 별도의 관리자를 만듭니다. 하드웨어 해시 키를 노트북에 삽입하거나 소프트웨어 라이센스를 활성화할 수 있습니다.
프로그래머에게 가장 큰 관심 사항은 "기능 할당 요구 사항"입니다.
따라서 보안 키가 있는 랩톱에서는 클러스터 서버에서 사용자를 시작하지 않으려면 "정보 보안에 대한 클라이언트 연결" 요구 사항 개체에 대한 "요구 사항"을 추가해야 합니다. - "할당하지 않음", 즉 이 서버의 작업자 프로세스가 클라이언트 연결을 처리하지 못하도록 합니다.
더욱 흥미로운 점은 사용자 세션 없이 클러스터의 프로덕션 서버에서 "백그라운드 작업만" 실행할 수 있는 기능입니다. 이렇게 하면 로드가 많은 작업(코드)을 별도의 시스템으로 이동할 수 있습니다. 또한 한 컴퓨터에서는 "추가 매개 변수 값"을 사용하여 "월 마감"이라는 백그라운드 작업을 실행할 수 있으며, 다른 컴퓨터에서는 "전체 텍스트 인덱스 업데이트"라는 백그라운드 작업이 "값 설명"을 통해 발생합니다. 추가 매개변수”입니다. 예를 들어 BackgroundJob.CommonModule을 값으로 지정하면 클러스터의 작업자 서버 작업을 콘텐츠가 있는 백그라운드 작업으로만 제한할 수 있습니다. BackgroundJob.CommonModule..- 값은 특정 코드를 나타냅니다.
문서를 다시 말할 필요가 없다는 것이 분명합니다. 하지만 누군가 유용한 조언을 해준다면 기사를 확장하겠습니다.
용어, 개념
1C 서버가 필요한 이유는 무엇입니까?
"서버 클러스터"라는 용어는 공통 작업을 수행하는 여러 컴퓨터(서버)를 의미합니다.
1C:Enterprise 8 서버 클러스터가 해결한 작업은 아래 그림에 나와 있습니다.
8.1과 8.2의 차이점
클러스터 1C 8.1
1C:Enterprise 8.1 서버 클러스터는 클라이언트 요청을 처리하는 서버에 대한 부하 분산 아이디어를 구현한 것입니다. 이 메커니즘은 하나의 서버 또는 여러 서버(“작업 서버”) 내의 컴퓨팅 리소스에 대한 로드를 분산시켜 애플리케이션 확장을 보장합니다. 서버 클러스터는 클라이언트 연결을 제공하는 코드를 복제합니다. 클러스터의 중복 실행 코드 이름은 "작업자 프로세스"(rphost)입니다. 클러스터를 설치하면 하나의 작업자 프로세스만 생성됩니다.
한 서버에 있는 여러 작업자 프로세스를 사용하면 RAM 및 프로세서 리소스 양을 효과적으로 사용하여 요청을 실행할 수 있을 뿐만 아니라 현재 작업이 "충돌"되는 경우 클라이언트 세션을 다른 작업자 프로세스에 연결할 수 있습니다.
Server Agent(ragent) 프로그램은 특정 서버에서 실행 중인 작업을 이해하는 역할을 담당합니다. 서버 에이전트를 중지하면 클러스터에서 서버를 사용할 수 없게 됩니다. 에이전트는 해당 정보를 srvribrg.lst 파일에 저장합니다.
작업 데이터베이스 및 관련 작업 프로세스에 대한 정보는 "서버 관리자"(rmngr)가 소유합니다. 이 정보는 1CV8Reg.lst 파일에 저장됩니다. 서버 관리자를 중지하면 관리자가 성공적으로 다시 시작되는 경우 클라이언트 애플리케이션이 다시 시작되거나 전체 클러스터의 작업 서버가 완전히 중지될 수 있습니다.
1C:Enterprise 8.1을 사용하면 하나의 서버에 여러 개의 독립적인 클러스터를 생성할 수 있습니다. 각각은 고유한 "IP 포트"와 서비스 파일의 고유 번호로 네트워크에서 식별됩니다. 첫 번째 클러스터는 기본적으로 포트 1541을 수신합니다.
엔터프라이즈 서버 스냅인은 클러스터를 관리하도록 설계되었습니다.
서버 이름이나 IP 주소로 서버에 연결할 수 있습니다.
서버 에이전트
서버 에이전트는 서버에서 실행 중인 모든 클러스터에 대해 "알고 있습니다". 이 정보는 클러스터 목록 및 관리자 목록과 함께 srvribrg.lst 파일에 저장됩니다. 에이전트의 기본 포트는 1540입니다. 각 작업 서버에서는 하나의 에이전트만 시작할 수 있으며 이 서버에서 가능한 모든 클러스터를 서비스합니다.
더 자세한 정보를 시각적으로 얻으려면 Process Explorer 유틸리티(Sysinternals에서 개발)를 사용하십시오. 이 프로그램을 사용하면 1C:Enterprise 8.1 서버 클러스터를 포함하여 실행 중인 모든 프로세스 내부를 더 자세히 살펴볼 수 있습니다.
클러스터 관리자
클러스터 관리자는 클러스터의 운영을 담당합니다. 각 클러스터에는 자체 관리자가 있습니다. 관리자는 클러스터에 대한 정보를 1CV8Reg.lst(클러스터 레지스트리) 파일에 저장합니다. 각 클러스터 관리자에는 작업 서버에도 자체 포트가 있습니다. 첫 번째 클러스터의 경우 기본 관리자 포트는 1541입니다. 클러스터 분기의 1C:Enterprise Servers 스냅인에 표시되어 클러스터를 식별하는 포트는 이 포트입니다.
관리자는 1C:Enterprise 8.1의 클라이언트 부분으로부터 요청을 받고 이 서비스 요청을 제공할 워크플로를 결정합니다.
Manager는 서비스 포트를 사용하여 작업자 프로세스와 상호 작용합니다.
작업 과정
작업 프로세스는 "고객과의 작업"을 담당합니다. 1C:Enterprise 8.0의 이전 버전에는 "워크플로"가 하나만 있었다고 말할 수 있습니다.
1C:Enterprise 8.1 클러스터에는 여러 작업자 프로세스가 있을 수 있습니다. 서버 관리자는 클라이언트 연결을 제공할 작업자 프로세스를 결정합니다. 클라이언트 연결의 경우 작업자 프로세스에는 기본적으로 1560 – 1591 범위의 IP 포트가 할당됩니다. 또한 각 작업자 프로세스에는 클러스터 관리자와의 통신을 위한 서비스 포트가 할당됩니다. 32비트 운영 체제에서 각 작업자 프로세스는 최대 2GB의 RAM을 사용합니다. 64비트 운영 체제에서는 RAM의 물리적 용량에 따라 제한이 적용됩니다.
클러스터 1C 8.2
서버 클러스터 1C:Enterprise 8.2 – 서버 8.2 기술의 추가 개발.
서버는 "8.1처럼" 작동할 수 있습니다. 이전 기술과의 호환성은 유지됩니다.
또한 서버 운영에 대한 새로운 접근 방식이 구현되었습니다. 이제 프로세스 대신 세션이 중요한 역할을 합니다.
세션은 관리되는 애플리케이션 내에서 로드 밸런싱 및 내결함성을 활성화합니다.
클러스터 관리자
클러스터 관리자는 이제 더욱 복잡해졌습니다. 이제 일부 기능을 별도의 프로세스로 분리하고 클러스터의 다른 작업 서버에 배치할 수도 있습니다. 이를 통해 서버 부하의 균형을 맞출 수 있습니다.
Server 8.2 내결함성은 다음을 통해 달성됩니다.
- 사용자 세션에 대한 정보를 저장합니다.
- 사용자는 더 이상 워크플로에 묶여 있지 않습니다.
- 클러스터의 작업 프로세스 예약.
- 중복 프로세스를 포함하여 여러 작업자 프로세스가 있어야 합니다.
- 클러스터 예약.
- 연결되면 예비 클러스터가 표시되며 연결 라인에 나열됩니다.
이는 작업의 연속성을 허용합니다.
클러스터에 대한 클라이언트의 물리적 연결이 끊어진 경우(청소부가 케이블을 뽑았거나 네트워크 장비의 전원이 꺼졌거나 공급자에 문제가 있었던 경우) 정보베이스에 다시 연결하여 모든 것을 시작할 필요가 없습니다. 작업을 다시 시작합니다. 물리적 연결이 복원된 후 사용자는 중단된 지점부터 작업을 계속할 수 있습니다.
클러스터 컴퓨터의 유지 관리가 필요한 경우 사용자가 정보 기반 작업을 중단하지 않고 작동 중에 끌 수 있습니다.
클러스터의 서버 중 하나라도 오류가 발생하더라도 사용자 작업은 중단되지 않으며 자동으로 백업 클러스터 및/또는 백업 작업 프로세스로 전송됩니다. 사용자에게는 이러한 전환이 보이지 않습니다.
클러스터의 작업자 프로세스 중 하나가 실패하면 이에 연결된 사용자는 자동으로 다른 작업자 프로세스나 백업 작업자 프로세스로 전송됩니다. 이러한 전환은 사용자에게도 보이지 않습니다.
클러스터 1C 8.3
서버 8.3은 새롭게 재설계된 내부 코드가 특징이지만 "외부에서"는 약간 수정된 8.2처럼 보일 수 있습니다.
서버는 더욱 "자동 구성 가능"해졌습니다. 작업자 프로세스 수와 같은 일부 매개변수는 더 이상 수동으로 생성되지 않고 내결함성 및 안정성 작업 요구 사항에 대한 설명을 기반으로 계산됩니다.
시스템 전체의 성능을 높이거나 새로운 "메모리 절약" 모드를 사용하여 구성이 제한된 경우 "제한된 메모리로" 작업할 수 있는 로드 밸런싱 메커니즘이 개발되었습니다. "기억을 잡아먹는 걸 좋아해요"라는 말을 사용했어요.
대용량 메모리 사용 시 작동 안정성은 프로덕션 서버의 새로운 매개변수에 따라 결정됩니다.
"호출당 안전한 메모리 소비" 매개변수는 특히 흥미롭습니다. 그것이 무엇인지 거의 모르는 사람들에게는 "생산적인" 방식으로 훈련하지 않는 것이 좋습니다. "작업 프로세스의 최대 메모리 크기" 매개변수는 "오버플로"의 경우 전체 작업 프로세스를 중단시키지 않고 "패자"가 있는 하나의 세션만 허용합니다. "서버가 생산적인 것으로 간주되는 작업 프로세스 메모리의 양"을 사용하면 이 메모리 임계값을 초과하는 즉시 새 연결을 차단할 수 있습니다.
예를 들어 "프로세스당 정보 보안 수 = 1"이라는 매개변수를 지정하는 등 정보 기반별로 작업 프로세스를 격리하는 것이 좋습니다. 로드가 많은 여러 데이터베이스를 사용하면 안정성과 성능 측면에서 상호 영향이 줄어듭니다.
라이센스/키의 "지출"은 시스템 안정성에 대한 별도의 기여입니다. 8.3에서는 "알라딘" 관리자를 연상시키는 "소프트웨어 라이선스 관리자"를 사용하는 것이 가능해졌습니다. 목표는 키를 별도의 컴퓨터에 배치할 수 있는 것입니다.
이는 클러스터 관리자에서 또 다른 "서비스"로 구현됩니다. 예를 들어 "무료" 노트북을 사용할 수 있습니다. 1C 8.3 클러스터에 추가하고 "라이선스 서비스" 서비스를 사용하여 별도의 관리자를 만듭니다. 하드웨어 해시 키를 노트북에 삽입하거나 소프트웨어 라이센스를 활성화할 수 있습니다.
프로그래머에게 가장 큰 관심 사항은 "기능 할당 요구 사항"입니다.
따라서 보안 키가 있는 랩톱에서는 클러스터 서버에서 사용자를 시작하지 않으려면 "정보 보안에 대한 클라이언트 연결" 요구 사항 개체에 대한 "요구 사항"을 추가해야 합니다. - "할당하지 않음", 즉 이 서버의 작업자 프로세스가 클라이언트 연결을 처리하지 못하도록 합니다.
더욱 흥미로운 점은 사용자 세션 없이 클러스터의 프로덕션 서버에서 "백그라운드 작업만" 실행할 수 있는 기능입니다. 이렇게 하면 로드가 많은 작업(코드)을 별도의 시스템으로 이동할 수 있습니다. 또한 한 컴퓨터에서는 "추가 매개 변수 값"을 사용하여 "월 마감"이라는 백그라운드 작업을 실행할 수 있으며, 다른 컴퓨터에서는 "전체 텍스트 인덱스 업데이트"라는 백그라운드 작업이 "값 설명"을 통해 발생합니다. 추가 매개변수”입니다. 예를 들어 BackgroundJob.CommonModule을 값으로 지정하면 클러스터의 작업자 서버 작업을 콘텐츠가 있는 백그라운드 작업으로만 제한할 수 있습니다. BackgroundJob.CommonModule 값입니다.<Имя модуля>.<Имя метода>- 특정 코드를 나타냅니다.
가능한 설치 문제 해결
1C:Enterprise 8.1 서버 부분을 설치할 때 새 사용자를 생성하거나 기존 계정을 선택할 수 있습니다.
기존 계정을 선택하는 경우 올바른 비밀번호와 확인을 제공해야 하며, 그렇지 않으면 백엔드를 시작하면 오류가 발생합니다.
클러스터 에이전트를 처음 실행하면 기본 클러스터가 생성됩니다.
기본 클러스터에는 다음과 같은 특징이 있습니다.
· 포트 번호 – 1541;
· IP 포트 범위 – 1560:1591;
· 다양한 작업 흐름 지원 - 비활성화됨;
· 하나의 작업자 프로세스, 포트 번호는 지정된 범위에서 설정됩니다.
Cluster Agent를 처음 시작할 때 문제가 발생하면 기본 클러스터가 생성되지 않을 수 있습니다. 이는 서버 에이전트(ragent)가 시작되면 시작되지만 다른 클러스터 프로세스(rmngr, rphost)는 시작되지 않는다는 사실에서 나타납니다. 클러스터 srvribrg.lst 목록은 다음과 같습니다.
{
{0},
이 경우 ragent 프로세스를 중지하고 클러스터 목록(srvribrg.lst)을 삭제한 후 ragent를 다시 시작할 수 있습니다.
서버 에이전트 서비스를 시작하기 위한 명령줄의 포트 매개변수에 지정된 포트와 클러스터 콘솔의 중앙 서버 매개변수 대화 상자에 지정된 포트가 일치하는지 확인합니다.
— 1C:Enterprise 8.1 서버 에이전트 서비스를 중지합니다.
서버 에이전트가 응용 프로그램으로 실행 중인 경우 Ctrl+C 키 조합을 눌러 중지할 수 있습니다.
- 작업 관리자에서 모든 프로세스 ragent, rmngr, rphost가 종료되었는지 확인하세요. 필요한 경우 작업 관리자를 사용하여 완료하세요.
— 1C:Enterprise 8.1 서버 에이전트 서비스의 속성을 엽니다.
- "실행 파일"(실행 파일 경로) 줄에 주의하세요. 여기에는 -d 매개변수와 클러스터 데이터 디렉토리가 있습니다. 클러스터와 관련된 모든 파일은 이 디렉터리에 있습니다.
- 이 디렉터리의 모든 내용을 삭제합니다.
— 1C:Enterprise 8.1 서버 에이전트 서비스를 시작합니다.
- 작업 관리자에서 모든 프로세스 ragent, rmngr, rphost가 시작되었는지 확인하십시오.
— 클러스터 콘솔을 실행하고 여기에 중앙 서버를 등록합니다. 콘솔은 중앙 서버에 연결되어야 하며 기본적으로 생성된 하나의 클러스터를 표시해야 합니다.
서버 클러스터 오류로 인해 발생할 수 있는 문제로는 보안 키, 서비스 계정 권한, 잘못된 시작 매개변수 문제 등이 있습니다.
- 서버 보호 키는 기업의 각 서버에 로컬로 설치됩니다.
- 빈 비밀번호로 서비스 계정을 설정하지 마세요.
- 여러 클러스터의 경우 사용되는 포트가 겹쳐서는 안 됩니다.
1C:Enterprise 8.1 플랫폼 설치 과정에서 오류 메시지가 표시될 수 있습니다. 가장 가능성이 높은 메시지는 다음과 같습니다. 메시지가 발생한 이유와 이를 제거하는 단계가 표시됩니다.
오류 1069: 로그인 오류로 인해 서비스가 실행되고 있지 않습니다.
문제는 시스템 서비스로 실행되는 계정의 권한과 관련이 있습니다. 로컬 보안 정책 유틸리티를 열고 사용자(대신 클러스터 작업 서버가 실행되는 사용자)를 서비스로 로그온 및 일괄 작업으로 로그온 정책에 추가합니다.
서비스 파일에 저장된 데이터가 손상된 경우 클러스터의 프로덕션 서버가 시작되지 않을 수 있습니다. 1C:Enterprise 8.1 서버 에이전트가 실행 중인지 확인하십시오(작업 관리자의 ragent 프로세스).
Windows 이벤트 감사도 분석 도구라는 점을 잊지 마십시오. 이렇게 하려면 Windows 이벤트 로그에 "의심스러운" 메시지가 나타나는지 확인하십시오.
오류 8007056B / 800708C5
새 비밀번호가 비밀번호 정책을 충족하지 않습니다. 비밀번호가 너무 짧거나 최근에 이미 이 비밀번호를 사용했을 수 있습니다.
이유: "1C:엔터프라이즈 서버 설치" 대화 상자에 지정된 계정 비밀번호가 보안 정책 요구 사항을 충족하지 않습니다.
해결 방법: 선택한 계정에 대해 보안 정책 요구 사항을 충족하거나 적용된 보안 정책 요구 사항을 약화시키는 새 비밀번호를 설정하십시오. "복잡한" 비밀번호를 요구하지 말고, 비밀번호의 문자 수를 제한하지 말고, 반복 시도를 확인하지 마세요.
오류 1923: 서비스별로 설치할 수 있는 권한이 없습니다.
원인: 오류는 계정의 응용 프로그램 설치 권한과 관련되어 있습니다. 이 오류는 강화된 보안 조치가 필요한 도메인 컨트롤러에 서버를 설치하려고 할 때 일반적으로 발생합니다.
해결 방법: 도메인 컨트롤러를 사용하여 엔터프라이즈 서버를 호스팅하거나 보안 요구 사항을 완화하고 선택한 계정에 대해 "서비스로 실행" 또는 "일괄 작업으로 실행" 권한을 지정하지 마십시오.
오류 80070056
비밀번호를 변경할 수 없습니다. 각 비밀번호는 최소 x일 동안 사용해야 합니다.
원인 및 해결 방법: 사용된 비밀번호에 대한 보안 정책 요구 사항을 위반할 때 발생하는 또 다른 오류입니다. 해결 방법은 오류 800708C5와 유사합니다.
Windows 소켓 - 11004(0x00002AFC)
1) 작업 관리자의 클러스터 작업 서버에서 다음이 실행되고 있는지 확인하십시오.
서버 에이전트(ragent.exe),
클러스터 관리자(rmngr.exe),
클러스터 작업자 프로세스(rphost.exe).
2) IP 주소 이름 확인을 확인하려면 명령줄에서 다음을 실행합니다.
ping 시스템 이름
명령에 대한 시스템의 응답에서 우리는 IP 주소가 결정되는지 여부를 확인하는 데 관심이 있습니다.
3) 이름은 결정되었으나 여전히 작업자 프로세스를 찾을 수 없는 경우 이름의 IP 주소가 결정되었는지 확인합니다.<имя машины>그리고<имя машины>.<имя домена>다르게 정의되지 않습니다.
(Windows 소켓 - 10054(0x00002746).
원격 호스트가 연결을 강제로 종료했습니다.
서버를 재부팅하거나 작업자 프로세스를 강제로 삭제해야 하는 경우 이 메시지가 나타날 수 있습니다.
이 오류는 일반적으로 다시 연결할 때 나타나지 않습니다. 오류가 계속되면 클러스터의 프로덕션 서버에 장애가 발생한 이유를 조사해야 합니다.
이 오류는 작업자 프로세스가 32비트 시스템에서 최대 메모리 용량에 도달할 때 발생할 수 있습니다.
또 다른 경우는 오류 메시지가 표시된 클라이언트의 연결 시도입니다.
(Windows 소켓 - 10060(0x0000274C)
연결 설정 시도가 실패했습니다. 이유는 다음과 같습니다. 필요한 시간 내에 다른 컴퓨터에서 필요한 응답을 받지 못했거나, 이미 연결된 컴퓨터의 잘못된 응답으로 인해 이미 설정된 연결이 종료되었습니다.
이 오류의 본질은 특정 시간(시간 초과) 내에 응답이 없다는 것입니다.
1) 방화벽이 애플리케이션 트래픽을 차단하고 있지 않은지 확인하십시오. 방화벽을 끄십시오.
이렇게 하려면 명령줄에서 다음 명령을 실행합니다(명령은 Windows XP 및 Windows Server 2003부터 사용할 수 있습니다. 이전 버전에는 방화벽이 내장되어 있지 않지만 타사 소프트웨어를 설치할 수 있습니다).
넷쉬방화벽세트작동 모드장애를 입히다
명령이 성공하면 다음 메시지를 받게 됩니다.
좋아요.
방화벽 외에도 네트워크 필터가 트래픽을 차단할 수 있습니다. 기본적으로 비활성화되어 있습니다. 그러나 다음과 같은지 확인하십시오.
- 네트워크 연결 폴더를 엽니다.
- 구성하려는 네트워크 연결을 마우스 오른쪽 버튼으로 클릭하고 선택합니다. 속성.
- 탭에서 흔하다(로컬 네트워크를 통해 연결하는 경우) 또는 탭에서 그물(다른 모든 연결의 경우) 선택 인터넷 프로토콜(TCP/IP)그리고 버튼을 누르세요 속성.
- 버튼을 클릭하세요 추가적으로.
- 탭 열기 옵션, 옵션을 선택하세요 TCP/IP 필터링그리고 버튼을 누르세요 속성.
- 체크박스를 확인하세요. TCP/IP 필터링 활성화(모든 어댑터)제거됨.
2) 프로세서 리소스가 100% 로드되지 않았는지 확인하십시오(CPU%).
3) 클라이언트 및 서버 인터페이스의 네트워크 활동을 측정합니다. 네트워크 어댑터의 부하는 60%를 초과해서는 안 됩니다.
(Windows 소켓 - 10061(0x0000274D)
연결이 설정되지 않았습니다. 대상 컴퓨터가 연결 요청을 거부했습니다.
이 오류가 발생하는 일반적인 이유는 실행 중인 서버 에이전트가 없기 때문입니다. 서버를 수동으로 시작하거나 서버를 재부팅하여 자동으로 시작합니다.
질문에 대한 답변
멀티플랫폼 1C
서버 설치
Q: MS Server 2008 R2 x64에 1c 서버를 설치하는 동안 오류가 발생했습니다. 명령줄을 통해 1c 서버를 설치할 때(예: ragent.exe -instsrvc -port 2040 -regport 2041 -range 2060:2091 -d “C:\Program Files\1cv82) \(ITS 디스크에서 가져옴) 명령줄에 다음 메시지가 기록됩니다. “오류! OpenSCManager 오류!” 이 경우 서비스가 생성되지 않습니다. 8.1.15.14 및 8.2.10.77에서 테스트되었습니다.
A: UAC가 있는 OS의 명령줄에서 설치하려면 RunAs 서비스를 사용해야 합니다. 사용자가 관리자 그룹의 구성원인 경우에도 UAC는 시스템 상태를 변경하는 작업을 차단합니다.
보호 키
Q: Server 8.2용 보호 키를 사용하면 Server 8.1을 실행할 수 있습니까?
A: 네, 그렇죠
Q: 1C 서버를 시작하려면 일종의 서버 해시 키가 필요합니까? 로컬입니까, 아니면 5명의 사용자에게는 작동하지 않습니까?
A: 예, 서버에는 자체 키가 필요합니다. 로컬 사용자 및 네트워크 키는 작동하지 않습니다. 자세한 내용은 « « , 슬라이드 번호 30.
Q: 1C 서버 클러스터가 3개의 물리적 서버로 구성되어 있다고 가정해 보겠습니다. 몇 개의 보안 키가 필요합니까?
Q: 터미널 서버와 5개의 라이센스에 대한 키가 있습니다. 6번째 추가 라이센스를 구입해야 합니다. 특허. 5시 키 옆 서버에 설치 가능한가요? 그리고 6명의 사용자 모두 터미널 세션에서 작업합니까, 아니면 5명은 터미널에서, 1명은 파일 버전에서 작업합니까?
A: 아니요, 그렇지 않습니다. 로컬 키 형태의 6번째 라이선스는 사용자의 컴퓨터에 연결되어야 하며, 단말기에는 연결되어 있지 않습니다.
1C 서버 업데이트
Q: 플랫폼의 새 버전 8.2.xxx가 출시되면 서버와 클라이언트를 업데이트하는 절차는 무엇입니까?
A: 8.2 배포판은 파일을 다른 폴더에 설치합니다(각 버전에는 자체 폴더가 있음). 이론적으로는 여러 버전의 서버를 병렬로 호출하는 것이 가능합니다.
나는 아무런 문제가 없었습니다. 그러나 1C 서버 인스턴스가 차지하는 포트를 주의 깊게 모니터링해야 합니다. 교차점이 없어야 합니다.
1C 서버 설정
Q: 1C 8.1에서 정보 기반이 여러 개인 경우 하나의 클러스터에 배치하거나 각 데이터베이스에 대해 별도의 클러스터를 생성하는 가장 좋은 방법은 무엇입니까? A: 볼륨이나 로드가 큰 경우 테스트 데이터베이스를 별도의 클러스터에 배치해야 합니다!
Q: 질문: 1C:Enterprise 8.1 워크플로는 단일 스레드 애플리케이션입니까, 아니면 다중 스레드 애플리케이션입니까? 저것들. 한 명의 연결된 사용자로 많은 코어를 로드할 수 있습니까? 여러 개로? 1C:Enterprise 8.2 워크플로는 어떻습니까? 감사합니다.
A: 버전 8.1의 1Сv8.exe 및 rphost.exe는 1개의 코어를 사용했습니다. 8.1에서는 클라이언트 연결이 작업자 프로세스와 엄격하게 연결되어 있으므로 1C 클라이언트 처리가 단일 코어 내에서 수행된다고 조건부로 가정할 수 있습니다. 1C 서버의 작동 방식에 관계없이 커널을 사용하는 DBMS는 예외입니다.
버전 8.2에서는 연결이 세션으로 대체됩니다. 세션이 이미 다른 작업자 프로세스에서 실행 중일 수 있습니다. 따라서 8.2 단일 스레드를 호출하는 것은 아마도 올바르지 않을 것입니다. 클라이언트 8.2는 또한 여러 코어를 시각적으로 로드하므로 다음과 같습니다.
플랫폼 8.2는 멀티 스레드 시스템의 모든 기능을 구현하지는 않지만 병렬 처리 측면을 포함하여 8.1에 비해 하드웨어 기능을 훨씬 더 잘 활용합니다.
Q: 여러 개의 코어를 로드하려면 데이터베이스 서버(MS SQL)에 대해 여러 개의 1C:Enterprise 8.1 작업 프로세스가 필요합니까? (MS SQL은 일반적으로 하나의 코어만 "로드"합니다. 즉, 하나의 요청을 여러 코어에 걸쳐 처리하는 "병렬화"는 원칙적으로 발생하지 않습니다.) 감사합니다.
A: MS SQL을 특별히 관리할 필요는 없습니다. 필요에 따라 리소스를 사용하는 상당히 자체 튜닝되는 시스템입니다. 실행 병렬성을 제어할 수 있습니다.
EXEC sys.sp_configure N'최대 병렬도', N'5'
가다
재정의로 재구성
가다
하나의 작업 프로세스가 작업 프로세스가 충돌하는 경우 사용자가 다시 연결할 수 있는 기능을 제공하지 않는다는 사실을 기반으로 1C 서버에서 여러 작업 프로세스를 생성할 수 있습니다. 프로세스 2(8.2에서는 "백업"으로 만드는 것이 더 좋음)는 이 문제를 해결합니다. 그러나 처음 두 작업 프로세스의 로드가 과중한 경우(90% 이상)에만 세 번째 이상의 작업 프로세스를 추가하는 것이 합리적입니다. 불필요하게 작업 프로세스를 늘리는 것은 의미가 없습니다. 이는 생산성을 저하시킬 수 있습니다.
A: 8.2에는 백업 작업자 프로세스가 1개 이상 있어야 합니다.
장애 조치 클러스터
Q: 1s 8.2 클러스터의 중복성 활성화에 대한 질문입니다. 서버가 충돌한 경우(청소부가 전선을 뽑은 경우) 네트워크 이름(예: "server:2540")을 사용할 수 없습니다. 연결 문자열이 "server:2540"인 클라이언트는 백업 클러스터에 연결해야 한다는 것을 어떻게 알 수 있습니까? 다른 서버의 이름은 어디서 알 수 있나요? 데이터베이스 연결 문자열에 쉼표로 구분된 클러스터를 쓰면 어떻게 될까요?
A: 여러 클러스터가 "중복 그룹"으로 결합됩니다. 이를 위해 클러스터 스냅인에 "예약 목록"이 있습니다.
클라이언트가 클러스터에 처음 접속하면 이중화 그룹에 포함된 클러스터 목록이 제공됩니다.
클라이언트가 귀하에게 연락한 적이 없다면 이 경우 모든 클러스터의 주소를 수동으로 지정해야 합니다(예: storm:2541,monster:2541).
중복 클러스터 간에 동기화된 데이터가 교환됩니다.
Q: 기본 클러스터가 복원된 후에는 어떻게 되나요? 사용자가 백업으로 전환한 경우
A: 그들은 돌아가고 있어요. 이러한 클러스터를 동기화하는 동안 전환하는 동안 일시 중지가 발생할 수 있습니다.
백그라운드 작업
Q: 서버 1C:8.1 및 1C:8.2에서 실행 중인 백그라운드 작업을 삭제하는 방법은 무엇입니까?
A: 일상적인 작업을 취소하는 기능은 내장된 1C:Enterprise 언어 내에서 코드가 실행되는 경우에만 작동합니다. 코드가 외부 라이브러리에서 실행되는 경우 워크플로를 강제로 종료하는 것 외에는 해당 작업을 취소할 수 없습니다. 프로세스에 StartTransaction() - CommitTransaction() 블록이 있으면 그럴 가능성이 없습니다. 다른 백그라운드 작업은 작업 콘솔을 통해 삭제할 수 있습니다.
규제 절차
Q: T&I 중에 기지를 파괴하는 것이 가능한가요?
A: 나는 그런 경우를 알지 못하지만 IMHO 무엇이든 가능합니다. 그러므로 근태관리 전 백업을 해두시는 것이 좋습니다.
Q: Vyacheslav, 1C 테스트 및 수정을 사용하여 재인덱싱을 수행하지 않는 이유는 무엇입니까?
A: DBMS 기능은 기본적으로 인덱스도 재구축하지만 데이터베이스를 독점적으로 점유할 필요가 없기 때문에 이러한 목적에 더 적합합니다.
기술 매거진
Q: 안녕하세요. 기술 잡지의 질문: 1C 오류가 발생할 경우 워크스테이션 화면의 사본을 받아야 합니다. 이를 위해 워크스테이션에 기술 로그를 설정해야 합니까, 아니면 서버에만 적용됩니까?
A: 플랫폼이 떨어질 때만 스크린샷을 받도록 구성할 수 있으며, 오류가 있을 때는 스크린샷을 받을 수 없습니다. 그러나 이러한 작업에는 기술적인 로그를 사용하여 예외 상황을 수집하는 것만으로는 충분하지 않습니다. 동시에 대부분의 오류는 1C 서버 측에서 TZ를 사용하여 볼 수 있습니다. 오래된 메타데이터 캐시와 관련된 "형식 스트림 오류"와 같은 이벤트는 예외입니다.
문제와 오류
Q: 8.2 플랫폼에서 구성을 동적으로 업데이트할 때 사용자에 대한 보고서 설정이 사라지는 문제가 발생했습니까? 이 문제를 해결하는 방법에 대한 권장 사항이 있습니까?
A: 동적 업데이트와 관련된 문제는 "1C 서버: Enterprise 8.1 및 8.2 - 무엇과 함께 먹을 것인가"), 슬라이드 번호 60. 캐시를 지웁니다. 어떤 경우에는 사용자 설정이 정확히 어디에 저장되어 있는지 이해해야 할 수도 있습니다. 필요한 경우 정보 레지스터에 바이너리 데이터로 저장합니다.
Q: 관련 질문입니다. 왜냐하면... 이는 파일 모드와 관련이 있습니다. chdbfl.exe는 어떤 오류를 수정합니까?
A: 이것은 데이터 저장 구조 오류 수정 도구입니다. 예를 들어 "데이터베이스 파일이 손상되었습니다.../1Cv8.1CD"가 나타나는 상황일 수 있습니다. 저것들. 데이터베이스 파일 손상을 수정합니다. 단, T&I 기능은 수행하지 않습니다. T&I가 성공적으로 실행되지 않으면 chdbfl.exe를 실행합니다.
Q: 이러한 문제가 발생한 경우 알려주십시오. 데이터베이스에 사용자 수가 많은 경우(약 40명) 대용량 문서를 처리할 때, 예를 들어 reg에 PO를 반영하는 경우입니다. 약 8000 라인을 차지합니다. 오류 메시지는 엔터프라이즈 1C 서버에 메모리가 부족하여 이 문서를 시작한 사용자가 실패한다는 것입니다. 그러면 1C 서버 에이전트를 다시 시작한 후에만 문서를 처리할 수 있습니다.
A: 메모리 누수가 발생한 것 같습니다.
1. 1C 서버를 다시 시작하고 작업자 프로세스 수를 늘리며 클러스터에 이 데이터베이스 하나만 유지합니다.
2. 한 번에 1000줄씩 홀딩을 부분적으로 이깁니다. TZ를 사용하면 작업 시작 시 메모리를 차지하지만 완료 시 메모리를 해제하지 않는 개체를 추적할 수 있습니다.
3. x64 버전을 설치하고 RAM 용량을 늘린 후 8.2로 전환합니다.
Q: 테스트 및 관리에 관한 질문입니다. 전송된 데이터를 기반으로 선택하여 URDB를 기반으로 "참조 무결성 검사"를 실행할 수 있습니까? (즉, 일부 노드에는 물리적으로 개체가 없지만 해당 개체에 대한 링크가 있습니다). 감사합니다!
A: 안타깝게도 아직은 불가능합니다.
Q: 테스트하고 수정하면 모든 문제가 한 번에 해결되지 않는 이유는 무엇입니까? 여러 번 실행해야 합니까?
A: 정확한 답변은 개발자만이 할 수 있습니다. 나는 규정에 따라 (주기적으로) T&I를 운영하고 있기 때문에 이 문제는 나와 별로 관련이 없습니다. T&I는 한번이 아닌 '자동차 MOT'처럼 지속적으로 이루어져야 합니다.
Q: T&I 8.1과 8.2의 차이점이 있나요?
A: 답변을 작성하고 8.2.10을 릴리즈하는 시점에서는 차이점을 모르겠습니다.
Q: 구조조정 중에 재색인을 해야 합니까?
답: 필요하지 않습니다.
다른
Q: MSSql 2008을 사용하여 데이터베이스 미러링을 시도한 사람이 있습니까?
Q: 서버 1s 8.2에서 공유 메모리를 강제하는 것에 대한 질문
A: 아무것도 강요할 필요가 없습니다. 서버가 이해해 줄 것입니다.
Q: 1C:Enterprise 8.1의 경우 동일한 하드웨어에서 "과중한" 작업이 포함된 파일 서버 버전과 단일 사용자가 클라이언트-서버 버전보다 훨씬 빠르게 작업하는 상황이 발견되었습니다. 서버, 1C 서버 :Enterprise 및 클라이언트)는 동일한 서버에 설치됩니다. 또한 이러한 "과중한" 작업을 수행할 때 명백한 하드웨어 과부하가 없습니다(프로세서, 메모리 및 하드 드라이브에 대한 부하가 최소화됨). 즉, 하드웨어 리소스는 많지만 작동 속도가 느립니다. 우리는 무엇에 대해 “안심”할 수 있습니까? 감사합니다.
A: 성능 관점에서 클라이언트-서버 아키텍처의 장점은 데이터에 대한 클라이언트 요청을 병렬로 처리할 수 있다는 것입니다. 저것들. 유속은 일반적인 결론을 도출하는 지표가 아닙니다. 동시성을 향상시키는 메커니즘은 여전히 단일 스레드 내에서 성능을 약간 저하시킬 수 있습니다.
귀하의 경우 병목 현상을 명확하게 찾으려면 서버 장비의 작업 부하를 확보하고 클라이언트-서버 모드에서 가장 긴 작업과 시간을 비교해야 합니다. 종종 이는 클라이언트 측으로의 과도한 데이터 이동입니다. 저것들. 1C 서버에서 작업을 수행하는 대신 데이터베이스의 데이터가 서버를 통해 클라이언트로 전송됩니다.
클라이언트-서버 버전의 한 스레드 속도는 파일 버전의 성능을 따라잡을 뿐입니다. 절대적인 숫자로 작업 시간을 측정하는 경우 이 문제를 해결할 가치가 있습니다. 1~3초 쿼리 내에서 최적화하는 것은 의심스럽습니다.
Q: Windows 터미널과 1C 씬 클라이언트의 차이점에 대해.
A: 대부분의 솔루션이 8.2로 완전히 번역될 때까지는 이러한 기술을 실질적으로 비교하기가 확실히 어렵습니다.
1C 씬 클라이언트는 트래픽을 덜 소비하고 웹을 통해 작업할 수 있는 기능을 제공해야 한다는 것이 분명합니다. 그러나 이는 아직 구현되지 않았으며 현재 터미널 솔루션이 매우 널리 사용되고 있습니다.
8.1을 8.2로 변환하는 보수적이고 실용적인 프로젝트 관리자를 위한 터미널 솔루션입니다. 오류 비용이 낮고 관리 양식 및 액세스 제어 시스템으로 즉시 구현되는 구성이 있는 소규모 프로젝트의 경우 씬 클라이언트가 IMHO를 선호합니다.
Q: 실제 조건에 가깝게 부하 테스트를 수행하는 방법은 무엇입니까? 결국, 사용자에게 "뭔가를 클릭"하도록 강요할 수는 없습니다.
A: 1C: 가장 어려운 작업을 선별한 테스트 센터입니다. 100% 재현이 필요하지 않으며 클릭 자체도 어렵지 않으며 주로 보고서를 수행하고 요청합니다. 테스트에 관한 별도의 웹 세미나가 있을 예정입니다. 저도 자세히 말씀드리겠습니다.
우선 1C 클러스터를 설치한 후 워크플로우를 생성해야 했습니다. 결과적으로 데이터베이스 부하에 따라 클러스터 프로세스가 자동으로 생성되기 시작했습니다.
기본 데이터베이스의 백그라운드 작업 테스트 실행으로 인해 1C 클러스터가 rphost.exe를 끝없이 오버로드했으며 추가 rphost.exe가 생성되는 것을 원하지 않았습니다. 설정을 파헤친 후에 모든 것이 명확해졌습니다.
최대 워크플로 메모리작업자 프로세스가 함께 사용할 수 있는 메모리 양입니다. 바이트 단위로 측정되는 매개변수를 설정할 때는 매우 주의해야 합니다. 잘못된 값을 설정하면(일반 사용자 작업에는 충분하지 않음) "1C 서버에 여유 메모리가 부족합니다."라는 오류가 사용자에게 표시됩니다. 1C 서버의 메모리 할당량이 부족한 경우에도 이 오류가 발생할 수 있습니다.
호출당 안전한 메모리 소비– 서버 호출 중 바이트 단위로 측정되는 메모리 소비를 제어할 수 있습니다. 호출이 예상보다 많은 메모리를 사용하는 경우 작업자 프로세스(rphost.exe)를 다시 시작하지 않고 1C 클러스터 내에서 이 호출이 완료됩니다. 따라서 서버 호출을 한 "패자"는 다른 사용자의 작업에 영향을 주지 않고 1C 데이터베이스와의 세션을 잃게 됩니다.
1GB – 1073741824바이트, 따라서 2GB – 2147483648바이트
서버가 생산적인 것으로 간주되는 작업 프로세스에 대한 메모리 양 - 이 매개 변수를 초과하면 1C 클러스터의 서버가 새 연결 수락을 중지합니다.
프로세스별 정보보안 건수– 작업 프로세스에 대한 정보 기반을 분리할 수 있습니다. 기본적으로 현재 1C 클러스터는 “ 8 "그러나 몇 시간 동안 작동하는 동안 서버가 매우 불안정하게 작동하고 사용자 세션이 정지되었습니다. 각 정보베이스(값 – "1")를 분리한 후 문제가 사라졌습니다.
프로세스당 연결 수- 기본값 " 128 “. 현재 데이터베이스에는 백그라운드 작업(물류 계산, 가격표 분석, 경쟁사 분석 등)이 매우 많기 때문에 그 수를 "25"로 줄이기로 결정했습니다.
1C 클러스터 자체의 설정이 약간 변경되었습니다.
내결함성 수준– 동시에 장애가 발생할 수 있는 작업 서버의 수이며 이로 인해 사용자가 비정상적으로 종료되지는 않습니다. 지정된 내결함성을 보장하는 데 필요한 양만큼 백업 서비스가 자동으로 시작됩니다. 실시간으로 활성 서비스가 백업 서비스에 복제됩니다.
부하 공유 모드– 매개변수에는 두 가지 옵션이 있습니다. “성능별 우선순위” – 더 많은 서버 메모리가 소비되고 성능이 더 높습니다. “메모리별 우선순위” – 1C 클러스터는 서버 메모리를 절약합니다.
서버 8.3은 새롭게 재설계된 내부 코드가 특징이지만 "외부에서"는 약간 수정된 8.2처럼 보일 수 있습니다.
서버는 더욱 "자동 구성 가능"해졌습니다. 작업자 프로세스 수와 같은 일부 매개변수는 더 이상 수동으로 생성되지 않고 내결함성 및 안정성 작업 요구 사항에 대한 설명을 기반으로 계산됩니다.
이렇게 하면 서버 구성이 잘못될 가능성이 줄어들고 관리자에 대한 자격 요구 사항이 낮아집니다.
시스템 전체의 성능을 높이거나 새로운 "메모리 절약" 모드를 사용하여 구성이 제한된 경우 "제한된 메모리로" 작업할 수 있는 로드 밸런싱 메커니즘이 개발되었습니다. "기억을 잡아먹는 걸 좋아해요"라는 말을 사용했어요.
대용량 메모리 사용 시 작동 안정성은 프로덕션 서버의 새로운 매개변수에 따라 결정됩니다.
"호출당 안전한 메모리 소비" 매개변수는 특히 흥미롭습니다. 그것이 무엇인지 거의 모르는 사람들에게는 "생산적인" 방식으로 훈련하지 않는 것이 좋습니다. "작업 프로세스의 최대 메모리 크기" 매개변수는 "오버플로"의 경우 전체 작업 프로세스를 중단시키지 않고 "패자"가 있는 하나의 세션만 허용합니다. "서버가 생산적인 것으로 간주되는 작업 프로세스 메모리의 양"을 사용하면 이 메모리 임계값을 초과하는 즉시 새 연결을 차단할 수 있습니다.
예를 들어 "프로세스당 정보 보안 수 = 1"이라는 매개변수를 지정하는 등 정보 기반별로 작업 프로세스를 격리하는 것이 좋습니다. 로드가 많은 여러 데이터베이스를 사용하면 안정성과 성능 측면에서 상호 영향이 줄어듭니다.
라이센스/키의 "지출"은 시스템 안정성에 대한 별도의 기여입니다. 8.3에서는 "알라딘" 관리자를 연상시키는 "소프트웨어 라이선스 관리자"를 사용하는 것이 가능해졌습니다. 목표는 키를 별도의 컴퓨터에 배치할 수 있는 것입니다.
이는 클러스터 관리자에서 또 다른 "서비스"로 구현됩니다. 예를 들어 "무료" 노트북을 사용할 수 있습니다. 1C 8.3 클러스터에 추가하고 "라이선스 서비스" 서비스를 사용하여 별도의 관리자를 만듭니다. 하드웨어 해시 키를 노트북에 삽입하거나 소프트웨어 라이센스를 활성화할 수 있습니다.
프로그래머에게 가장 큰 관심 사항은 "기능 할당 요구 사항"입니다.
1c의 할당된 기능에 대한 요구 사항
따라서 보안 키가 있는 랩톱에서는 클러스터 서버에서 사용자를 시작하지 않으려면 "정보 보안에 대한 클라이언트 연결" 요구 사항 개체에 대한 "요구 사항"을 추가해야 합니다. - "할당하지 않음", 즉 이 서버의 작업자 프로세스가 클라이언트 연결을 처리하지 못하도록 합니다.
더욱 흥미로운 점은 사용자 세션 없이 클러스터의 프로덕션 서버에서 "백그라운드 작업만" 실행할 수 있는 기능입니다. 이렇게 하면 로드가 많은 작업(코드)을 별도의 시스템으로 이동할 수 있습니다. 또한 한 컴퓨터에서는 "추가 매개 변수 값"을 사용하여 "월 마감"이라는 백그라운드 작업을 실행할 수 있으며, 다른 컴퓨터에서는 "전체 텍스트 인덱스 업데이트"라는 백그라운드 작업이 "값 설명"을 통해 발생합니다. 추가 매개변수”입니다. 예를 들어 BackgroundJob.CommonModule을 값으로 지정하면 클러스터의 작업자 서버 작업을 콘텐츠가 있는 백그라운드 작업으로만 제한할 수 있습니다. BackgroundJob.CommonModule 값입니다.<Имя модуля>.<Имя метода>– 특정 코드를 나타냅니다.
