확장성요구 사항의 확대와 해결해야 할 작업의 양 증가에 적응할 수 있는 시스템의 능력입니다.

다양한 조건에서 하나의 애플리케이션 솔루션 운영

1C:Enterprise 8 시스템은 뛰어난 확장 기능을 갖추고 있습니다. 이를 통해 파일 버전과 클라이언트-서버 기술을 모두 사용하여 작업할 수 있습니다.

• 개인적인 용도, 작품의 파일 버전
  파일 버전에서 작업할 때 플랫폼은 사용자가 작업 중인 동일한 컴퓨터에 있는 로컬 정보 베이스와 함께 작동할 수 있습니다. 이 작업 옵션은 집에서나 노트북에서 작업할 때 사용할 수 있습니다.
• 소규모 작업 그룹, 작업의 파일 버전
  파일 옵션은 또한 여러 사용자가 하나의 정보 기반을 사용하여 로컬 네트워크에서 작업할 수 있는 기능을 제공합니다. 이러한 작업 방식은 소규모 작업 그룹에서 사용할 수 있으며 설치 및 작동이 쉽습니다.
• 대기업, 클라이언트-서버 버전의 작업
  대규모 작업 그룹 및 엔터프라이즈 규모의 경우 1C:Enterprise 8 서버와 별도의 데이터베이스 관리 시스템을 사용하는 3계층 아키텍처를 기반으로 클라이언트-서버 버전의 작업을 사용할 수 있습니다. 다수의 사용자가 동시에 작업할 때 안정적인 데이터 저장과 효율적인 처리를 제공합니다.
• 정보베이스 보유, 분산
  대규모 지주 회사는 파일 및 클라이언트-서버 작업 옵션을 모두 사용하여 분산된 정보 기반에서 작업을 사용할 수 있습니다. 분산된 정보 기반을 사용하면 서로 멀리 떨어져 있는 지주 회사의 부서를 통합할 수 있으며, 이러한 각 부서는 차례로 파일 또는 클라이언트-서버 옵션을 사용할 수 있습니다. 분산 정보 기반의 메커니즘은 분산 시스템에 포함된 개별 정보 기반 간의 데이터 보유 및 교환 데이터의 각 부서에서 사용되는 구성의 신원을 보장합니다.

파일 및 클라이언트-서버 작동 모드 모두에서 동일한 애플리케이션 솔루션(구성)을 사용할 수 있다는 점에 유의하는 것이 중요합니다. 파일 버전에서 클라이언트-서버 기술로 전환할 때 애플리케이션 솔루션을 변경할 필요가 없습니다. 따라서 작업 옵션 선택은 전적으로 고객의 요구와 재무 능력에 달려 있습니다. 초기 단계에서는 파일 버전으로 작업할 수 있으며, 사용자 수와 데이터베이스 볼륨이 증가함에 따라 정보 기반에서 작업하는 클라이언트-서버 버전으로 쉽게 전환할 수 있습니다.

다중 사용자 작업

시스템 확장성의 주요 지표 중 하나는 해결해야 할 작업 수, 처리되는 데이터 양 및 집중적으로 작업하는 사용자 수의 증가에 따라 효과적으로 작업할 수 있는 능력입니다.

클라이언트-서버 버전은 많은 수의 사용자가 병렬로 작업할 수 있는 기능을 제공합니다. 테스트 결과, 사용자 수가 증가함에 따라 문서 입력 속도가 매우 느리게 감소하는 것으로 나타났습니다. 이는 집중 사용자 수가 증가함에 따라 자동화된 시스템의 응답 속도가 허용 가능한 수준으로 유지된다는 것을 의미합니다.

1C:Enterprise 8 시스템에서 지원하는 데이터 모델에는 여러 사용자가 동시에 액세스하게 되는 데이터베이스 테이블이 없습니다. 동시 접근은 논리적으로 연관된 데이터에 접근할 때만 발생하며, 주제 영역 관점에서 서로 연관되지 않은 데이터에는 영향을 미치지 않습니다.

일상적인 작업을 수행할 때 특정 보고 기간에 작업을 시작하기 위해 전용 모드를 설치해야 하는 상황은 제외됩니다. 사용자와 조직에 편리한 시간에 일상적인 작업을 수행할 수 있습니다. Exclusive 모드는 시스템 시작 시 설치되는 것이 아니라 활성화가 필요한 작업을 수행해야 하는 순간에 설치됩니다. 이러한 작업을 수행한 후 단독 모드를 비활성화할 수 있습니다.

최적화 메커니즘

1C:Enterprise 8 기술 플랫폼에는 애플리케이션 솔루션의 속도를 최적화하는 다양한 메커니즘이 포함되어 있습니다.

서버에서 실행

클라이언트-서버 버전에서는 1C:Enterprise 8 서버를 사용하면 가장 광범위한 데이터 처리 작업에 집중할 수 있습니다. 예를 들어 매우 복잡한 쿼리를 실행할 때 사용자를 위해 실행되는 프로그램은 필요한 선택 항목만 수신하고 모든 중간 처리는 서버에서 수행됩니다. 일반적으로 서버 용량을 늘리는 것은 전체 클라이언트 시스템을 업그레이드하는 것보다 훨씬 쉽습니다.

데이터 캐싱

1C:Enterprise 8 시스템은 개체 기술을 사용할 때 데이터베이스에서 읽은 데이터를 캐싱하는 메커니즘을 사용합니다. 객체 속성에 액세스하면 모든 객체 데이터가 RAM에 있는 캐시로 읽혀집니다. 동일한 개체의 세부 정보에 대한 후속 호출은 데이터베이스가 아닌 캐시로 전송되므로 필요한 데이터를 검색하는 데 소요되는 시간이 크게 줄어듭니다.

서버에 내장된 언어 작업

클라이언트-서버 버전에서 작업할 때 응용 프로그램 개체의 모든 작업은 서버에서만 수행됩니다. 양식 및 명령 인터페이스의 기능도 서버에서 구현됩니다.

서버는 양식 데이터를 준비하고 요소를 정렬하며 변경 후 양식 데이터를 기록합니다. 클라이언트는 서버에 이미 준비된 양식을 표시하고 데이터를 입력하며 서버를 호출하여 입력된 데이터와 기타 필요한 작업을 기록합니다.

마찬가지로 명령 인터페이스도 서버에서 구성되어 클라이언트에 표시됩니다. 또한 보고서는 전적으로 서버에서 생성되어 클라이언트에 표시됩니다.

버전 8.1 및 8.0 - 성능 및 확장성 비교

다양한 조건에서 시스템의 성능과 확장성이 어떻게 변경되었는지 평가하기 위해 버전 8.1에서 여러 테스트가 수행되었습니다.

• 다수의 사용자가 동시에 작업할 때 시스템 성능 및 확장성 평가
• 최대 부하 시 시스템 성능 및 확장성 평가
• 특정 유형의 작업에 대한 성과 평가

1C:Enterprise 8.1에 대해 얻은 지표를 유사한 지표와 비교했습니다.

1C:엔터프라이즈 8의 경우.

버전 7.7 및 8.0 - 성능 및 확장성 비교

1C:Enterprise 8의 클라이언트-서버 버전의 성능과 확장성을 평가하기 위해 다음과 같은 여러 테스트가 수행되었습니다.

• 표준 작동 모드에서 1C:Enterprise 8의 장점을 비교하고 보여줍니다.
• 로드 강도가 증가하고 처리된 데이터의 양이 증가함에 따라 1C:Enterprise 8의 확장성을 평가합니다.
• 사용되는 장비의 컴퓨팅 리소스를 늘리면서 1C:Enterprise 8의 확장성을 평가합니다.
• 최대 부하 조건에서 작동할 때 1C:Enterprise 8의 성능과 성능을 평가합니다.
• 1C:Enterprise 문제를 해결하기 위해 다중 프로세서 플랫폼을 사용하는 효과를 평가합니다. 8.

제조 기업 관리 솔루션의 확장성 평가

많은 수의 사용자가 동시에 작업할 때 제조 기업 관리(PEM) 애플리케이션 솔루션의 확장성을 평가하기 위해 테스트가 수행되었습니다.

테스트를 수행할 때 기업 정보 시스템의 성능을 평가하기 위해 일반적으로 허용되는 접근 방식이 사용되었습니다.

• 일반적인 애플리케이션 솔루션을 테스트하는 데 사용합니다.
• 일반적인 조직의 운영 관점에서 가장 중요한 테스트 작업입니다.
• 대부분의 조직에서 일반적으로 사용되는 고정 매개변수 하에서의 테스트 작업
• 실제 사용자가 생성한 부하를 훨씬 초과하는 부하를 생성하여 시스템 사용자를 위한 일반적인 작업 시나리오의 소프트웨어 시뮬레이션
• 단위 시간당 시스템에 반영되는 비즈니스 트랜잭션의 양과 작업을 완료하는 데 걸리는 평균 시간을 주요 지표로 사용합니다.

"제조 기업 관리" 솔루션 구현을 위한 기술 매개변수의 예

이 섹션에서는 다양한 규모와 프로필의 기업에서 "1C:Enterprise 8. 제조 기업 관리" 구현의 기술적 매개변수에 대한 자세한 정보를 게시합니다.

이 섹션의 목적은 IT 전문가에게 실제로 사용되는 장비에 대한 데이터와 실제 1C:Enterprise 8 구현 부하의 예를 익히는 것입니다.

이 정보는 1C:Enterprise 8 시스템의 모든 프로그램 사용자에게도 유용할 수 있습니다.

장비 선택

이 문서는 장비 특성이 다양한 모드에서 시스템 사용 효율성에 어떤 영향을 미치는지에 대한 정보를 제공하고 해결되는 작업에 따라 장비 선택에 대한 권장 사항을 제공합니다.

1C:성과관리센터 - 성과 모니터링 및 분석 도구

1C:성능 관리 센터(1C:PMC)는 1C:Enterprise 8 플랫폼에서 정보 시스템의 성능을 모니터링하고 분석하기 위한 도구입니다. 1C:PMC는 시스템 성능을 평가하고 기존 성능 문제에 대한 자세한 기술 정보를 수집하고 분석하도록 설계되었습니다. 이 정보는 추가 최적화를 위해 사용됩니다.

1C:TestCenter - 부하 테스트 자동화 도구

1C:TestCenter는 1C:Enterprise 8 플랫폼에서 정보 시스템의 다중 사용자 로드 테스트를 자동화하는 도구입니다. 이 도구를 사용하면 실제 사용자의 참여 없이 기업 운영을 시뮬레이션할 수 있으므로 적용 가능성을 평가할 수 있습니다. , 실제 상황에서 정보 시스템의 성능 및 확장성.

플랫폼에 기업 정보 시스템 구현
1C:엔터프라이즈 8

1C:Enterprise 8 플랫폼에서 애플리케이션 솔루션을 구현한 경험을 통해 이 시스템을 통해 한 작업장 자동화부터 엔터프라이즈 규모 정보 시스템 생성에 이르기까지 다양한 수준의 복잡성 문제를 해결할 수 있음을 알 수 있습니다.

동시에 대규모 정보 시스템을 구현하면 중소 규모 구현에 비해 더 많은 요구 사항이 적용됩니다. 기업 규모의 정보 시스템은 경쟁 모드에서 동일한 정보와 하드웨어 자원을 사용하는 다수의 사용자가 동시에 집중적으로 작업하는 조건에서 수용 가능한 성능을 제공해야 합니다.

올렉 스피랴예프

최근에는 중급 및 고급형 서버가 랙이나 클러스터로 통합된 보급형 서버 그룹으로 적극적으로 교체되고 있다는 주장이 자주 제기되었습니다. 그러나 일부 전문가들은 이에 동의하지 않습니다. 따라서 Dataquest에 따르면 2000년부터 2002년까지 전체 서버 판매에서 50만 달러 이상 가격의 모델(중급 및 고급 SMP 서버 포함)이 차지하는 비중은 38%에서 52%로 증가했습니다.

IDC가 얻은 다른 데이터는 2개의 프로세서를 사용하는 저가형 서버 모델 부문의 성장(적어도 시스템 수 측면에서)을 나타냅니다. IDC는 또한 2005년에 5만 달러에서 300만 달러 사이의 서버용 가장 일반적인 운영 체제는 Unix가 될 것이라고 예측합니다. 이 데이터를 비교해 보면 중급 및 고급형 Unix 서버가 데이터 센터의 주요 플랫폼으로 남을 것이 분명하지만 점점 더 많은 소형(보통 듀얼 프로세서) 서버로 보완될 것입니다.

이러한 추세는 데이터 센터에서 다양한 컴퓨팅 계층이 분리된 결과로 나타났습니다(그림 1). Tier 1, 즉 프론트 티어는 소규모 서버의 스케일 아웃 모델로 점진적으로 전환하는 반면, Tier 3(데이터베이스 티어)은 스케일 업 서버가 지배적입니다. 레이어 2(애플리케이션 레이어)는 수직적 아키텍처와 수평적 아키텍처가 공존하는 영역이 됩니다.

수직 및 수평 아키텍처

수직 아키텍처와 수평 아키텍처의 주요 차이점을 살펴보겠습니다. 확장형 서버는 4개 이상의 중앙 처리 장치를 갖춘 대규모 SMP(대칭적 다중 처리 또는 공유 메모리) 시스템입니다. 모든 프로세서, 메모리 및 I/O 구성 요소를 제어하기 위해 하나의 OS 복사본만 사용합니다. 일반적으로 이러한 모든 리소스는 하나의 랙이나 캐비닛에 보관됩니다. 이러한 서버는 대기 시간이 짧고 일관된 캐시 액세스를 제공하는 고속 중앙 또는 백플레인을 통해 상호 연결됩니다. 캐비닛 내부에 추가 마더보드를 설치하여 리소스를 추가할 수 있습니다. 타워 아키텍처(또는 SMP) 시스템에서는 메모리가 공유됩니다. 즉, 모든 프로세서와 I/O 구성 요소가 모든 메모리에 액세스할 수 있습니다. 사용자는 메모리를 하나의 큰 객체로 "인식"합니다.

수평적 확장에서는 시스템이 네트워크를 통해 연결되거나 함께 클러스터링됩니다. 상호 연결은 일반적으로 고속 이더넷, GBE(기가비트 이더넷), SCI(Scalable Coherent Interconnect)와 같은 표준 네트워크 기술을 사용하며 수직형 시스템보다 처리량은 낮고 대기 시간은 길다. 이 경우 리소스는 일반적으로 1~4개의 프로세서를 포함하는 노드에 분산됩니다. 각 노드에는 자체 프로세서와 메모리가 있으며 자체 I/O 하위 시스템을 갖거나 다른 노드와 공유할 수 있습니다. 각 노드는 별도의 OS 복사본을 실행합니다. 리소스는 노드를 추가하여 확장되지만 노드에 리소스를 추가하여 확장되는 것은 아닙니다. 수평 시스템의 메모리는 분산되어 있습니다. 즉, 각 노드에는 해당 프로세서 및 I/O 하위 시스템에서 직접 액세스할 수 있는 자체 메모리가 있습니다. 다른 노드에서 이러한 리소스에 액세스하는 것은 해당 리소스가 있는 노드에서보다 훨씬 느립니다. 또한 수평적 아키텍처에서는 노드 간에 메모리에 대한 일관된 액세스가 없으며 사용되는 애플리케이션은 상대적으로 적은 리소스를 소비하므로 단일 노드에 "적합"하고 일관된 액세스가 필요하지 않습니다. 애플리케이션에 여러 노드가 필요한 경우 일관된 메모리 액세스 자체를 제공해야 합니다.

수평적 시스템이 애플리케이션 요구 사항을 충족하는 경우 구입 비용이 더 낮기 때문에 이 아키텍처가 더 좋습니다. 일반적으로 수평형 시스템의 프로세서당 구입 비용은 수직형 시스템보다 낮습니다. 가격 차이는 수직 시스템이 보다 강력한 RAS(신뢰성, 가용성, 서비스 가능성) 기능과 고성능 상호 연결을 사용하기 때문에 발생합니다. 그러나 수평적 아키텍처를 사용하는 시스템에는 여러 가지 제한 사항이 있습니다. 아래에서는 수평 시스템을 사용할 수 있는 조건과 수직 확장이 필요한 경우에 대해 설명합니다.

하나의 대형 SMP 서버 외에도 수직 아키텍처에는 단일 대규모 애플리케이션에 사용되는 대형 SMP 서버 클러스터도 포함됩니다.

최근 시장에 등장한 모듈형 또는 블레이드 서버는 일반적으로 1개 또는 2개의 프로세서를 장착하는 것이 수평형 서버의 예입니다. 여기서 클러스터는 작은 노드로 구성되며, 각 노드에는 중앙 프로세서 수가 1~4개인 보급형 SMP 서버가 있습니다.

확장하는 또 다른 방법은 대규모 병렬 컴퓨팅(MPP) 시스템을 이용하는 것입니다. 이 시스템은 단일 캐비닛에 설치된 여러 소형 프로세서로 구성되며 각 프로세서에는 자체 OS 사본 또는 OS 마이크로커널 사본이 있습니다. 현재 전문 솔루션을 대표하는 소수의 MPP 시스템만 생산됩니다. 예를 들어 NCR에서 제조한 Terradata 시스템, IBM RS/6000SP(SP-2) 및 HP Tandem 논스톱이 있습니다.

표 1. 수직 및 수평 아키텍처의 특징

매개변수	수직 시스템	수평 시스템
메모리	대규모 공유	소형 전용
스트림	많은 상호 의존적 스레드	많은 독립 스레드
상호 연결	단단히 결합된 내부	느슨하게 결합된 외부
라스	강력한 RAS 단일 시스템	복제를 활용한 강력한 RAS
중앙 처리 장치	많은 표준	많은 표준
OS	다수의 중앙 프로세서를 위한 하나의 OS 사본	여러 개의 OS 사본(1-4 프로세서용 사본 1개)
공들여 나열한 것	한 옷장에는	랙에 다수의 서버 배치
밀도		단위 바닥 면적당 높은 프로세서 밀도
장비	표준 및 특수 설계	기준
스케일링	단일 서버 섀시 내에서	다중 서버 규모
확대	서버에 추가 구성 요소를 설치하여	새 노드를 추가하여
건축학	64비트	32비트 및 64비트

테이블 1은 수직 및 수평 아키텍처의 비교 분석을 허용합니다.

• 수직형 시스템은 메모리를 공유하고 일관된 캐시 액세스를 제공합니다.
• 수직 시스템은 서로 통신해야 하는 작업 흐름에 이상적입니다.
• 수직형 시스템은 강력한 RAS 기능이 특징이며, 수평형 시스템에서는 대규모 복제를 통해 가용성을 구현합니다. (여러 노드가 클러스터에 연결되어 있어 그 중 하나의 장애가 전체 시스템 운영에 미치는 영향이 거의 없습니다.)
• 수직 시스템에서는 하나의 OS 사본이 모든 리소스를 포괄합니다. Sun Microsystems의 미드프레임 및 고급 서버(Sun Fire 4800 ~ Sun Fire 15K)와 같은 일부 수직형 시스템은 더 작은 수직형 서버로 나눌 수 있습니다.
• 수직 시스템은 가능한 한 많은 표준 구성 요소를 사용하지만 일부 주요 구성 요소(예: 상호 연결)는 특별히 설계되었습니다.
• 기존 프레임에 추가 구성 요소(더 강력한 프로세서, 추가 메모리, 추가 및 고성능 I/O 연결 등)를 설치하여 수직 시스템을 확장할 수 있습니다. 노드를 추가하거나 기존 노드를 새 노드로 교체하여 수평 시스템을 확장합니다.
• 거의 모든 수직 시스템은 64비트인 반면 수평 시스템은 32비트 또는 64비트일 수 있습니다.

일부 유형의 애플리케이션에는 수직형 시스템이 더 적합하고 다른 애플리케이션에는 수평형 시스템이 더 적합하지만, 대부분의 경우 최적의 아키텍처 선택은 문제의 규모에 따라 달라집니다. 테이블에 그림 2는 수직 또는 수평 아키텍처가 최적인 애플리케이션의 예를 보여줍니다.

표 2. 수직 및 수평 아키텍처의 애플리케이션 유형

소형 및 모듈식 서버는 상태 비저장, 소규모, 쉽게 복제되는 애플리케이션에 매우 적합합니다. 그리고 시스템 내에서 집중적인 데이터 전송이 필요한 상태 정보와 대용량 데이터를 사용하는 애플리케이션의 경우 수직 서버가 이상적인 솔루션입니다. HPTC(고성능 기술 컴퓨팅) 시장에는 스레드들이 서로 의존하고, 서로 데이터를 교환하는 애플리케이션이 많다. 많은 양의 공유 메모리가 필요한 애플리케이션도 있습니다. 대형 SMP 서버는 이 두 가지 유형의 애플리케이션에 가장 적합합니다. 그러나 실행 스레드가 독립적이고 많은 양의 공유 메모리가 필요하지 않은 HPTC 응용 프로그램도 있습니다. 이러한 애플리케이션은 분할될 수 있으므로 소규모 서버 클러스터가 이를 실행하는 데 이상적입니다. 마찬가지로 일부 상용 응용 프로그램은 분할되어 수평 서버의 이점을 누리는 반면 다른 응용 프로그램은 분할할 수 없으므로 수직 서버가 가장 적합한 플랫폼입니다.

성능에 영향을 미치는 요인

모든 대규모 데이터 센터는 병렬 컴퓨터입니다. 여기서는 클러스터도 특수한 유형의 병렬 시스템으로 간주할 수 있습니다. 고성능을 위해서는 강력한 프로세서, 고속 상호 연결 및 I/O, 확장 가능한 OS, 최적화된 애플리케이션 및 고급 RAS 기능을 갖춘 균형 잡힌 시스템이 필요합니다.

프로세서 및 시스템 상호 연결

프로세서는 확실히 필수 구성 요소이지만 시스템의 전체 성능을 부분적으로만 결정합니다. 프로세서가 최대 용량으로 실행되는지 확인하는 것이 더 중요합니다. 50%만 로드된 강력한 프로세서는 80%만 로드된 느린 프로세서보다 성능이 떨어집니다.

또한 병렬 시스템의 프로세서 수가 증가함에 따라 프로세서 성능보다는 시스템 상호 연결이 중요해졌습니다. 그들은 디스크, 메모리, 네트워크에서 프로세서로 데이터를 이동하는 일을 담당합니다. 클러스터에서 상호 연결은 고속 이더넷 또는 기가비트 이더넷과 같은 네트워크 연결입니다. 클러스터 상호 연결은 노드 간에 데이터를 이동하는 반면, 시스템 상호 연결은 단일 시스템 내에서 데이터를 이동합니다. 상호 연결이 너무 느리면 프로세서는 데이터를 기다리며 유휴 상태가 됩니다.

시스템 상호 연결은 캐시 일관성을 지원하는 데 필요한 데이터 주소를 이동하는 데에도 사용됩니다. 시스템 상호 연결의 데이터 주소 전송 속도가 너무 느리면 프로세서는 데이터에 액세스하려면 해당 주소를 알아야 하기 때문에 다시 유휴 상태로 데이터를 기다리게 됩니다. 빠른 상호 연결은 높은 처리량과 짧은 대기 시간(데이터 요청이 이루어진 시점부터 데이터 전송이 시작될 때까지의 짧은 시간)을 제공합니다.

수평 시스템과 수직 시스템의 주요 기술적 차이점은 상호 연결의 처리량과 대기 시간입니다. 클러스터 상호 연결의 경우 처리량은 고속 이더넷의 경우 125MB/s부터 SCI의 경우 200MB/s까지 가능하며 대기 시간은 GBE의 경우 100,000ns, SCI의 경우 최대 10,000ns까지 가능합니다. InfiniBand 인터페이스를 사용하면 첫 번째 버전의 경우 약 250MB/s, 후속 버전의 경우 최대 3GB/s 범위의 최고 속도로 더 빠른 상호 연결을 구현할 수 있습니다.

입력과 출력

상호 연결이 디스크와 네트워크에서 데이터를 빠르게 검색하여 프로세서로 전송할 수 있도록 빠른 I/O가 필요합니다. I/O 하위 시스템의 병목 현상은 가장 빠른 상호 연결 및 프로세서의 성능에도 부정적인 영향을 미칠 수 있습니다.

운영 체제

OS의 확장성이 충분하지 않으면 최고의 하드웨어라도 무용지물입니다. 수평적 시스템의 경우 OS 확장성은 그다지 중요하지 않습니다. 단일 노드에서 또는 별도의 OS 복사본으로 실행되는 프로세서가 4개 이하이기 때문입니다.

시스템 가용성

일반적으로 시스템 가용성은 아키텍처 유형에 따라 크게 달라집니다. 대규모 SMP 시스템에서는 RAS 기능이 시스템에 내장되어 있으며 2~4개 노드에 대한 장애 조치로 보완됩니다. 수평적 시스템에서는 개별 노드의 RAS가 더 나쁘지만 이러한 기능의 향상은 노드를 여러 번 복제함으로써 달성됩니다.

최적화된 애플리케이션

애플리케이션은 컴퓨팅 시스템 아키텍처에 맞게 최적화되어야 합니다. SMP 시스템용 애플리케이션을 작성하고 최적화하는 것이 가장 쉽습니다. 주요 상용 애플리케이션은 SMP 시스템에 특별히 최적화되어 있으며 심지어 SMP 시스템에서 개발되기도 했습니다. 이것이 바로 SMP가 지난 10년 동안 중급 및 고급 시스템 시장을 장악해 온 이유입니다.

애플리케이션 크기

언급한 바와 같이 대규모 SMP 시스템은 고속 상호 연결을 사용하여 충분한 시스템 성능을 제공합니다. 수평 시스템은 노드 간에 데이터를 자주 전송해야 하는 경우 낮은 처리량과 높은 상호 연결 대기 시간으로 인해 성능 문제가 발생할 수 있습니다. 그러나 일부 애플리케이션(예: 웹 서버, 프록시, 방화벽 및 소규모 애플리케이션 서버)에서는 고성능을 달성하기 위해 높은 상호 연결 속도가 필요하지 않습니다. 일반적으로 작은 애플리케이션과 쉽게 복제할 수 있는 애플리케이션입니다. 이러한 수평 시스템에서 각 노드는 다른 모든 노드의 작업과 독립적으로 작은 작업을 수행합니다.

예를 들어, 수평(또는 분산 메모리) 아키텍처에서는 4개의 프로세서 노드(각각 별도의 RAM과 전용 또는 공유 I/O 하위 시스템이 있음)가 기가비트 이더넷과 같은 네트워크 상호 연결을 사용할 수 있습니다. 이 컴퓨팅 환경은 세 가지 유형의 워크로드를 실행합니다. 가장 작은 로드는 하나의 노드에 적합하지만, 증가함에 따라 이를 완료하려면 여러 노드가 필요합니다. 전문가들에 따르면 여러 노드에서 하나의 작업을 수행할 경우 노드 간 연결 속도가 느려 성능이 크게 저하된다고 합니다. 서로 통신할 필요가 없는 소규모 워크로드는 수평적 아키텍처에서 잘 작동하지만, 수평적 아키텍처에서 대규모 워크로드를 실행하는 데는 문제가 있습니다.

대규모 SMP 시스템 구성에는 최대 100개의 프로세서, 576GB의 공유 메모리, 고속 상호 연결 등이 포함될 수 있습니다. 이러한 시스템은 노드 간 통신이 없고 프로세스 간 효율적인 통신이 없기 때문에 모든 유형의 워크로드를 처리할 수 있습니다. 모든 중앙 처리 장치는 모든 디스크, 모든 메모리 및 네트워크 연결에 동시에 액세스할 수 있습니다. 이는 SMP 시스템(또는 수직 시스템)의 핵심 기능입니다.

대형 SMP에 작은 부하를 가하는 것이 타당성에 대한 의문이 종종 제기됩니다. 이는 기술적으로는 가능하지만 경제적인 관점에서 볼 때 이러한 접근 방식은 타당하지 않습니다. 대형 SMP의 경우 프로세서당 구입 비용이 소형 시스템보다 높습니다. 따라서 애플리케이션이 주요 관리 문제 없이 작은 노드(또는 여러 개의 작은 노드)에서 실행될 수 있는 경우 배포를 위한 확장이 더 나은 선택입니다. 그러나 응용 프로그램이 너무 커서 작은 노드(또는 여러 노드)에서 실행할 수 없다면 성능과 시스템 관리 측면에서 대규모 SMP 서버가 최선의 선택이 될 것입니다.

데이터베이스 수준 성능

여기서 주요 질문은 단일 중형 및 대형 SMP 서버의 성능을 소형 서버 클러스터(프로세서 4개 이하)와 비교하는 것입니다.

확장성을 논의할 때 제조업체에서는 다양한 기술 용어를 사용합니다. 따라서 SMP의 성능 향상(속도 향상)은 여러 프로세서와 하나의 프로세서에서 애플리케이션 실행 속도의 비율로 정의됩니다. 예를 들어, 선형 속도 향상은 40개 프로세서에서 애플리케이션이 하나보다 40배(40배) 빠르게 실행된다는 것을 의미합니다. 성능 향상은 프로세서 수에 따라 달라지지 않습니다. 즉, 24개 프로세서 구성의 경우 48개 프로세서 구성과 동일합니다. 클러스터 성능 향상(클러스터 속도 향상)은 계산할 때 프로세서 수가 아닌 노드 수를 사용한다는 점에서만 다릅니다. SMP 성능 증가와 마찬가지로 클러스터 성능 증가는 다양한 노드 수에 걸쳐 일정하게 유지됩니다.

확장 효율성은 애플리케이션, 특히 클러스터된 애플리케이션이 다수의 노드에 걸쳐 확장할 수 있는 능력을 특징으로 합니다. 일반적으로 확장 효율성은 측정에 참여하는 노드 수에 따라 달라집니다. SMP 확장 효율성은 성능 증가분을 프로세서 수로 나눈 값이고, 클러스터 효율성은 클러스터 성능 증가분을 클러스터에 포함된 노드 수로 나눈 값입니다. 두 노드의 90% 확장 효율성은 4개 노드의 90% 확장 효율성과 동일하지 않기 때문에 잘못된 그림을 얻지 않도록 이러한 매개 변수의 의미를 이해해야 합니다.

그림에서. 그림 2는 이상적인 선형 확장성, 95%의 24 프로세서 SMP 서버 확장성, 90%의 2개의 4 프로세서 서버 클러스터 확장성의 세 가지 그래프를 보여줍니다. 클러스터의 데이터베이스 확장성(수평적 확장 포함)에는 특정 제한이 있음을 알 수 있습니다. 많은 소형 서버를 함께 연결하면 중대형 애플리케이션에 필요한 확장성을 제공하지 않습니다. 그 이유는 클러스터 내 상호 연결의 대역폭 제한, 클러스터 관리와 관련된 데이터베이스 소프트웨어에 대한 추가 부담, 분산 메모리 클러스터 환경을 위한 애플리케이션 작성의 어려움 때문입니다.

예를 들어 공개된 벤치마크 결과에 따르면 Oracle9i RAC(Real Application Cluster)는 1.8의 성능 향상과 90%의 확장 효율성을 제공합니다. 이러한 확장성 효율성은 상당히 높은 것처럼 보일 수 있지만, 실제로 4개 노드에 대한 90%의 확장성은 대형 SMP 서버의 결과와 비교할 때 비효율적입니다.

애플리케이션 수준 성능

3계층 데이터 센터의 애플리케이션 계층은 데이터베이스 계층과 매우 다릅니다. 일반적으로 이 수준의 애플리케이션은 상태 비저장입니다. 즉, 서버 자체에 데이터가 저장되지 않거나 그 중 일부만 저장됩니다. 이 계층에는 애플리케이션 서비스에 대한 비즈니스 규칙이 포함되어 있습니다. 트랜잭션은 애플리케이션 수준에 도달하여 처리됩니다. 데이터를 쓰거나 읽어야 할 경우 트랜잭션이 데이터베이스 계층으로 전달됩니다. 연결 수가 많으면 성능에 부정적인 영향을 미치기 때문에 응용 프로그램 서버는 데이터베이스 연결을 통합하는 경향이 있습니다.

대부분의 경우 애플리케이션 서버 계층에는 개별 애플리케이션 서비스당 데이터베이스 계층보다 더 많은 프로세서가 필요합니다. 예를 들어, SAP R/3의 경우 이 비율은 각 데이터베이스 프로세서에 대해 약 10개의 프로세서입니다. 즉, SAP R/3에서 데이터베이스 계층에 대해 20개의 프로세서가 필요한 경우 애플리케이션 계층에 대해 약 200개의 프로세서가 있어야 합니다. 문제는 2프로세서 서버 100대와 20프로세서 서버 10대 중 어느 것을 배포하는 것이 더 수익성이 높느냐 하는 것입니다. 마찬가지로 Oracle에서는 애플리케이션 프로세서와 데이터베이스 프로세서의 비율이 약 5:1입니다.

애플리케이션 서버는 여러 노드에 분산될 필요가 없다고 생각됩니다. 응용 프로그램 소프트웨어의 여러 복사본은 용량이 다른 여러 물리적 서버나 대규모 서버의 동적 도메인에 분산될 수 있습니다.

애플리케이션 계층에 필요한 프로세서 수는 컴퓨터 아키텍처에 관계없이 거의 동일합니다. 이 경우 프로세서당 비용이 더 낮기 때문에 수평 아키텍처를 위한 하드웨어 및 소프트웨어 구매 비용은 더 낮습니다. 대부분의 경우 수평적 시스템은 서비스 수준 계약을 충족하는 데 필요한 성능을 제공할 수 있습니다. 소프트웨어 라이센스 구매와 관련된 비용은 두 아키텍처 모두 거의 동일합니다.

동시에 수평적 아키텍처의 인프라를 관리하고 유지하는 데 드는 비용은 더 높을 수 있습니다. 수평적 시스템에 배포하는 경우 OS 및 애플리케이션 서버 소프트웨어의 여러 복사본이 사용됩니다. 인프라 유지 관리 비용은 일반적으로 OS 및 애플리케이션 복사본 수에 비례하여 증가합니다. 또한 수평적 아키텍처를 사용하면 백업 및 재해 복구가 분산되고 네트워크 인프라를 관리하기가 더 어려워집니다.

시스템 관리 비용은 측정하기 어렵습니다. 일반적으로 수평적 및 수직적 애플리케이션 서버 배포를 비교하는 모델은 더 적은 수의 더 강력한 서버(수직형 서버)를 관리하는 것이 여러 개의 작은 서버를 관리하는 것보다 비용이 적게 든다는 것을 보여줍니다. 일반적으로 애플리케이션 계층을 배포하기 위한 아키텍처 유형을 선택할 때 IT 관리자는 하드웨어 구입 비용을 신중하게 고려해야 합니다.

아키텍처가 가용성에 미치는 영향

현대 데이터 센터에서는 가용성이 매우 중요합니다. 애플리케이션 서비스는 24x7x365(하루 24시간, 주 7일, 1년 365일) 제공되어야 합니다. 특정 데이터 센터의 요구 사항에 따라 다양한 고가용성 체계가 사용됩니다. 특정 솔루션을 선택하려면 허용 가능한 가동 중지 시간(계획 및 계획되지 않은)을 결정해야 합니다. 그림에서. 그림 3은 가용성 비율이 다운타임 기간에 어떤 영향을 미치는지 보여줍니다.

가용성 요구 사항이 증가함에 따라 솔루션 비용도 증가합니다. 데이터 센터 관리자는 서비스 수준 요구 사항을 가장 잘 충족하는 비용, 복잡성 및 가용성의 조합을 결정해야 합니다. 약 99.95%의 가용성이 필요한 데이터 센터에서는 전체 하드웨어 이중화 및 온라인 유지 관리와 같은 RAS 기능을 갖춘 단일 SMP 서버를 배포할 수 있습니다.

그러나 99.95% 이상의 가용성을 달성하려면 클러스터가 필요합니다. HA(고가용성) 장애 조치 기능을 갖춘 Sun Cluster 소프트웨어는 99.975% 가용성을 제공합니다. HA 장애 조치는 기본 서버와 상시 대기 서버를 사용합니다. 기본 서버에 오류가 발생하면 백업 서버가 해당 로드를 대신합니다. 서비스를 다시 시작하는 데 걸리는 시간은 애플리케이션에 따라 다르며 특히 트랜잭션을 복원하기 위해 대규모 데이터 집약적 롤백이 필요한 데이터베이스 애플리케이션의 경우 몇 분 정도 걸릴 수 있습니다.

데이터 센터에서 몇 분의 가동 중지 시간을 허용할 수 없는 경우 활성-활성 시스템이 솔루션이 될 수 있습니다. 여기서 애플리케이션은 두 개 이상의 노드에 배포되어 노드 중 하나가 실패하면 다른 노드가 계속해서 애플리케이션을 실행하게 됩니다. 결과적으로 중단 시간은 매우 짧고(일부 클라이언트에서는 1분 미만 지속된다고 보고함) 때로는 사용자가 노드 오류를 인지하지 못할 수도 있습니다.

수직 서버는 계획된 가동 중지 시간과 계획되지 않은 가동 중지 시간을 최소화하기 위해 단일 서버에 많은 RAS 기능을 내장하여 고가용성을 제공합니다. 수평형 서버에서는 높은 수준의 RAS를 제공하는 기능이 개별 서버 수준이 아닌 여러 서버의 이중화 및 배치를 통해 구현된다. RAS 기능 및 상호 연결의 다양한 구현으로 인해 수평 서버는 일반적으로 프로세서당 가격이 더 저렴합니다.

3계층 아키텍처의 경우 수평적 고가용성의 좋은 예는 웹 서버 배포입니다. 각각 별도의 웹 서버 소프트웨어 복사본이 설치된 여러 개의 소규모 서버를 배포할 수 있습니다. 하나의 웹 서버가 다운되면 해당 트랜잭션은 나머지 정상 서버에 재분배됩니다. 애플리케이션 서버의 경우 수평, 수직 서버 모두에서 호스팅이 가능하며, 이중화를 통해 고가용성을 구현한다. 몇 대의 대규모 SMP 서버를 배포하든 여러 개의 소규모 서버를 배포하든 중복성은 애플리케이션 수준에서 높은 RAS를 달성하는 주요 방법으로 남아 있습니다.

그러나 데이터베이스 수준에서는 상황이 달라집니다. 데이터베이스는 상태를 저장하며 그 특성상 대부분의 경우 모든 프로세서/노드에서 데이터를 분할하고 액세스할 수 있어야 합니다. 이는 중복성을 갖춘 고가용성을 위해서는 Sun Cluster 또는 Oracle9i RAC(매우 높은 가용성을 위해)와 같은 클러스터링 소프트웨어를 사용해야 함을 의미합니다.

결론

수직 및 수평 아키텍처 모두 오늘날의 데이터 센터에서 틈새 시장을 갖고 있습니다. 오늘날의 초점은 모듈식 서버 및 병렬 데이터베이스와 같은 신기술에 맞춰져 있지만 시장에서는 여전히 중급 및 고급 서버에 대한 수요가 높습니다.

수직 및 수평 시스템은 동일한 소프트웨어, OS, 심지어 동일한 프로세서를 사용할 수 있습니다. 가격과 성능에 영향을 미치는 주요 차이점은 각 아키텍처에 사용되는 상호 연결입니다. 수평 서버는 느슨하게 결합된 외부 상호 연결을 사용하는 반면, 수직 서버는 더 높은 데이터 전송 속도를 제공하는 긴밀하게 결합된 상호 연결을 사용합니다.

프런트엔드의 경우 수평형 서버는 일반적으로 성능, 총 구입 비용 및 가용성 측면에서 최적의 솔루션을 제공합니다. 애플리케이션 계층의 경우 수직 및 수평 아키텍처를 모두 효과적으로 사용할 수 있습니다. 데이터베이스 계층의 경우 필요한 가용성 수준에 관계없이 수직 서버를 사용하는 것이 최적의 솔루션입니다.

네트워크 물류 관리에 필요한 정보 시스템의 다양한 기능 중에서 먼저 두 가지 핵심 "네트워크" 기능, 즉 분류 관리와 카테고리 관리 지원에 중점을 둘 것입니다.

1. 네트워크 무역 회사의 구색 관리.

특히 식품 부문의 네트워크 소매 무역 기업은 관리 작업이 가장 복잡하다는 특징이 있습니다. 특히 어려운 것은 구색 관리입니다.

문제가 더 잘 해결될수록 소매 무역 기업 전체가 더 효율적으로 발전하고 경쟁력이 높아집니다.

구색 관리 작업은 "외부"와 "내부"의 두 가지 하위 작업으로 나눌 수 있습니다.

첫 번째는 구색 측면에서 구매자와 협력하는 것을 목표로 하고, 두 번째는 구색 카테고리를 통해 직원의 작업을 촉진하는 것을 목표로 합니다.

이러한 문제를 성공적으로 해결하면 제품 판매 실적이 향상됩니다.

효과적인 솔루션을 위해 "외부" 작업 그룹 필요한:

• 1) 고객에게 제품에 대한 정보를 제공합니다. 정보 및 멀티미디어 지원 시스템은 고객이 무한한 상품의 바다를 탐색하고 올바른 선택을 하며 최단 시간 내에 귀중한 정보를 얻을 수 있도록 설계되었습니다. 동시에 소매업체가 소비자 선호도를 분석하고, 필요한 상품의 판매를 촉진하고, 매장 레이아웃을 최적화하고, 분류를 합리적으로 배치하여 분류 관리 자동화라는 외부 작업의 성공적인 솔루션을 보장합니다.
• 2) 개인 마케팅 문제를 해결합니다. 개인 마케팅 기능의 구현은 "슈퍼마켓" 및 "하이퍼마켓" 형식에 대한 구색 관리의 가장 중요한 작업 중 하나입니다. 더욱이 슈퍼마켓의 경우 특정 매장의 특정 일반 고객의 선호도 변동을 추적하여 타겟 개인 마케팅을 수행하는 것이 가장 중요하다면 대형 슈퍼마켓의 경우 전통적으로 정의된 카테고리에 속하는 일반적인 고객 그룹과 협력하는 것이 중요합니다. 일반 고객의. 할인점의 경우 개인 마케팅은 관련성이 낮습니다. 일반 고객의 선호도를 파악하기 위해 정보 시스템에서 판매에 대한 종합적인 분석을 수행하고 구매 구조를 결정하는 능력의 가용성도 매우 중요한 작업입니다.
• 3) 고품질의 시각적 머천다이징을 수행합니다. 매장 진열대에 상품을 효과적으로 진열하면 판매량이 크게 늘어납니다. 시각적 머천다이징 문제에 대한 솔루션의 품질을 평가하려면 정보 시스템이 매장 선반의 상품 배치를 설명하는 플래노그램을 유지하고 분석할 수 있어야 합니다.

결정할 때 내부 분류 관리 업무 다음 비즈니스 프로세스를 자동화해야 합니다.

1) 적극적인 구색 관리 프로세스 (구색 매트릭스 유지).

사실, 일단 데이터베이스에 입력된 제품에 대한 정보는 오랫동안 데이터베이스에 남아 있습니다. 예를 들어, 현재 7,000개의 상품 품목이 분류되어 있는 경우 시스템은 20~30,000개의 상품 품목을 저장할 수 있습니다. 이러한 조건에서는 시스템 사용자에게 활성 분류에 대한 최신 정보만 사용하여 작업할 수 있는 기회를 제공해야 합니다(그림 3.4).

쌀. 3.4.

이 문제를 해결하려면 다음이 필요합니다. 다음 기능을 확인하십시오.

• 활성 구색에 상품을 도입합니다. 이 프로세스는 일반적으로 해당 제품에 대한 일련의 시험 마케팅 활동, 물류 준비 및 제품 사전 판매 준비가 선행됩니다.
• 활성 구색에서 상품을 제거하는 첫 번째 단계로 상품 구매를 중단합니다. 이 프로세스의 일반적인 이유는 다음과 같습니다.
  • a) 제품 판매 결과에 대한 불만
  • b) 제조업체에 의한 제품 구성 변경;
  • c) 공급자와의 관계 문제의 존재; 등등;
• 회사 유통 센터의 재고 보충 중단;
• 정보의 분류에서 제품을 제거하는 마지막 단계로서 제품 작업 중단

시스템(보통 준비금이 0에 도달할 때 발생)

금전등록기 시스템에서 상품에 대한 정보 삭제(보통 재고 처리 후 수행)

이 비즈니스 프로세스 자동화의 이점 :

• 제품군 작업 시 사용자의 편의성;
• 활성 분류에 속하지 않는 제품을 문서에 포함할 수 없는 것과 관련된 오류 수가 크게 감소합니다.
• 활성 구색에 대해서만 분석 보고서를 수신할 수 있는 기능
• 구색 관리에 관련된 관리자의 생산성 향상; 등등;
• 2) 다양한 형식의 활발한 소매 기업을 관리하는 프로세스 , 다중 형식 네트워크 무역 기업에 포함됨 (다중 구색 매트릭스 관리).

이 비즈니스 프로세스를 자동화하면 이 제품이 속하지 않는 분류 매트릭스인 관리 개체로의 상품 이동을 방지할 수 있습니다(그림 3.5).

쌀. 3.5.

또한 "내부" 분류 관리 문제에 대한 고품질 솔루션이 다중 형식 네트워크 소매 무역 기업에 가장 중요하다는 점에 유의해야 합니다.

2. 카테고리 관리 지원 프로세스특정 카테고리 관리자가 작업하는 제품 보기 및 관리 개체 보기의 형성을 통해.

소위 전략적 사업 단위로 결합된 특정 제품 범주의 관리에 관여하는 관리자의 경우 정보 시스템으로 작업할 때 제품 및 관리 개체의 특정 하위 집합에 집중하는 것이 중요합니다.

카테고리 관리자는 "자신의 제품 카테고리"와 관련된 것만 확인하여 자신의 사업부에 포함된 상품과 자신이 담당하는 관리 개체 외에는 정보 시스템에 아무것도 없다는 착각을 불러일으키는 것이 좋습니다.

관리자는 자신의 기능 프레임워크 내에서 자신이 일하는 전략적 사업 단위의 프리즘을 통해 물류 및 분석 정보를 제시하는 제품 흐름에 대한 관점을 만드는 것이 필요합니다.

이 모드에서 정보 시스템과의 작업을 보장하려면 제품 보기 및 관리 개체 보기를 할당하는 기능을 구현해야 합니다.

동시에 정적 및 동적이라는 두 가지 기본 유형의 제품 보기가 있습니다.

각 관리자는 자신의 전략적 사업 단위를 정의하는 자신만의 제품 관점을 가지고 있습니다. 이 경우 동일한 사업부를 담당하는 관리자에게 단일 보기가 할당됩니다.

정적 제품 보기를 정의하는 경우 제품 세트는 실제로 명명된 목록으로 기록됩니다(그림 3.6). 세트를 엄격하게 고정하는 데 편리합니다(예: 분석 수행).

쌀. 3.6.

사업부 정의를 위한 제품 뷰를 효과적으로 관리하려면 제품 분류기의 노드에서 정의하는 것이 좋습니다. 이러한 관점을 동적이라고 부르겠습니다(그림 3.7).

쌀. 3.7.

이 경우 카테고리 관리자의 동적 관점에 포함된 특정 하위 그룹에 신제품이 도입되자마자 해당 제품은 자동으로 전략적 사업 단위의 요소가 되고 관리자는 즉시 해당 제품에 대한 작업을 시작합니다.

제품이 다른 하위 그룹으로 이동되면(예: 분류 변경으로 인해) 다른 전략적 사업 단위로 이동되고 작업을 위해 자동으로 다른 범주 관리자에게 전송됩니다.

관리 개체 보기도 비슷한 방식으로 구성됩니다. 이는 특정 카테고리 관리자가 운영하는 매장 및 유통 센터 목록을 정의하는 정적 보기입니다(그림 3.8).

쌀. 3.8.

이 접근 방식을 통해 상품 제조업체 또는 공급업체를 포함한 시스템 사용자는 활성 제품 범위의 특정 하위 집합 및 해당 거래 대상 내에서 정보 시스템의 필요한 기능과 정보에 액세스할 수 있습니다.

이 기능은 공급업체나 제조업체가 "자신의" 상품의 공급망 관리에 참여할 때 VMI 물류 개념을 구현할 때 매우 중요합니다.

결론적으로 위의 내용을 바탕으로 몇 가지 결론을 도출해 보겠습니다.

• 1) 무역 기업의 구색을 관리하는 것이 가장 중요한 작업이며 솔루션의 품질이 성공을 직접적으로 결정합니다.
• 2) 외부 구색 관리 문제 그룹, 특히 대형 소매 기업에 대한 솔루션은 고객 정보 시스템(정보 키오스크, 멀티미디어 단말기, 정보 카트 등)을 제공하도록 설계되었습니다.
• 3) 정보 시스템에서 분류 매트릭스, 제품 보기 및 관리 객체 보기를 유지하는 능력은 무역 기업의 카테고리 관리 기능 구현 품질과 직접적으로 관련된 내부 분류 관리 작업 그룹을 해결하는 능력을 촉진합니다. .

정보시스템 확장성

온라인 소매 회사가 발전함에 따라 정보 시스템이 더 이상 비즈니스 성장을 지원할 수 없는 시점이 오는 경우가 있습니다. 따라서 회사의 성장에 있어 정보 시스템의 적절성에 대한 문제는 매우 중요합니다.

이 경우에는 시스템의 확장성과 성장에 대한 적절성이라는 두 가지 측면을 고려해야 합니다.

기업의 성장이 IT 인프라 비용의 불균형적인 증가를 동반한다면, 정보 시스템은 비즈니스 확장을 최적으로 지원할 수 없습니다.

회사의 성장에 부적합한 정보 시스템은 운영 비용의 급격한 증가로 이어질 수 있습니다.

우선, 솔루션 아키텍처는 회사의 성장에 부합해야 합니다. 회사가 성장하여 수백 개의 시설을 보유하게 되면 분산 아키텍처에 시스템을 구축한다는 것은 매장당 IT 지원 비용이 계속해서 증가한다는 것을 의미한다고 생각합니다.

100개 이상의 소매점을 관리하는 네트워크 회사의 맥락에서, 데이터를 중앙에 통합하면서 데이터를 동기화하는 것이 점점 더 어려워지고 이것이 불가능해지는 때가 옵니다.

정보 시스템의 확장성(필요한 수의 사용자를 제공하고, 만족스러운 성능으로 필요한 양의 정보를 운영하는 능력)을 보장하려면 올바른 플랫폼(적절한 소프트웨어 및 서버 하드웨어)을 선택해야 합니다.

소매 회사가 성장하는 경우 판매 정보의 양은 기가바이트가 아닌 테라바이트 단위로 계산되며 이는 Oracle, Progress 등과 같은 확장 가능한 "산업용" 데이터베이스 관리 시스템을 사용하지 않고는 불가능합니다.

다른 종류의 컴퓨팅 장비로 "마이그레이션"할 수 있는 운영 체제도 필요합니다.

정보 시스템을 선택하고 운영할 때 급속한 성장을 전략으로 삼는 소매 체인 회사가 정보 시스템의 확장성과 소유 비용을 심각하게 고려해야 한다는 것은 분명합니다.

우리는 회사가 성장함에 따라 분산 아키텍처가 비즈니스 관리 비용 절감 및 IT 인프라 운영에 큰 장애물이 된다고 확신합니다.

정보 시스템의 중앙 집중식 아키텍처는 낮은 소유 비용을 의미하며 소매 네트워크가 성장함에 따라 IT 인력 수를 지속적으로 늘릴 필요가 없습니다.

기업 시스템의 확장성은 추가 수정 없이 새로운 하드웨어와 소프트웨어를 연결하여 성능을 높일 수 있는 능력을 의미합니다. 이 점은 최신 컴퓨터 및 네트워크 기술을 사용할 때 중요합니다. 중앙은행과 그 지점의 분산 데이터 처리를 예로 들 수 있습니다.

확장성은 다양한 수준에서 달성됩니다. a) 기술; b) 전신; c) 네트워크 d) DBMS; d) 적용됩니다. OS의 경우 확장성은 OS가 단일 프로세서 아키텍처에 묶여 있지 않음을 의미합니다. 사용자가 직면하는 작업이 더욱 복잡해지고 컴퓨터 네트워크에 대한 요구 사항이 확장되는 경우 OS는 기업 네트워크에 더욱 강력하고 생산적인 서버와 워크스테이션을 추가할 수 있는 기능을 제공해야 합니다. 하드웨어, 소프트웨어의 확장성, 시스템 전체의 확장성을 고려할 수 있습니다. 확장성은 다음과 같은 기술을 기반으로 합니다. a) 국제 표준; b) 네트워크 및 통신 기술; c) 운영 체제 d) 클라이언트/서버 기술 및 기타 여러 수단.

작업 종료 -

이 주제는 다음 섹션에 속합니다.

경영 분야의 컴퓨터 정보 기술. 제어 시스템의 분류

CIS의 목적은 과학적이고 실용적인 문제를 해결하기 위한 도구로서 CIS 프레임워크 내에서 현대 정보 기술의 사용을 준비하는 것입니다. 정보 기술의 개념 기업 정보..

이 주제에 대한 추가 자료가 필요하거나 원하는 내용을 찾지 못한 경우 당사 저작물 데이터베이스에서 검색을 사용하는 것이 좋습니다.

받은 자료로 무엇을 할 것인가:

이 자료가 도움이 되었다면 소셜 네트워크 페이지에 저장할 수 있습니다.

트위터

이 섹션의 모든 주제:

정보 기술 개념. 기업 정보 기술
기술은 생산 과정에서 재료를 가공하는 방법과 제품을 생산하는 방법이 상호 연결된 시스템입니다. 정보기술은 상호 연결된 기술의 시스템이다.

정보처리기술. 상호 운용성, 개방성 및 모듈성의 개념
정보는 등록 및 처리 대상이 되는 일련의 사실, 현상, 관심 사건입니다. 이는 정보의 소스와 수신자(소비자)라는 두 가지 지점이 있음을 의미합니다.

정보시스템 지원 유형
ASOEI 지원 유형: a) 기술; b) 수학; c) 언어; d) 소프트웨어. 정보 지원 – 정보 분류 및 코딩 시스템, 처리 기술 체계

기업 정보 시스템의 아키텍처
CIS의 아키텍처는 여러 수준으로 구성됩니다. a) 정보-논리적 수준 – 데이터 흐름 및 원본, 소비 센터(노드) 집합입니다.

기업 정보 시스템 요구 사항
정보 처리 기술의 적극적인 개선 프로세스는 현대 정보 시스템(CIS)에 다음 요구 사항이 점점 더 많이 부과되고 있다는 사실의 결과입니다. a) 구조

기업 정보 시스템의 이질성. 기업 정보 시스템의 이질성 문제에 대한 솔루션
가장 중요한 역할은 기업 시스템의 이질성 문제를 극복하고 구성에 포함된 구성 요소의 호환성을 보장하는 문제입니다. 컴퓨팅 시스템의 이질성은 다음과 같은 원인이 될 수 있습니다.

컴퓨터 정보 기술 분야의 국제 표준
현재 ISO(국제 표준 기구), 더 정확하게는 ISO 기술 위원회에서 개발한 기업 품질 시스템 표준 세트가 전 세계적으로 널리 보급되었습니다.

컨트롤 객체의 정보 모델
현대 기업은 외부 및 내부 비즈니스 환경이 정보 소스인 효과적인 정보 센터로 간주될 수 있습니다. 외부 비즈니스 환경 –

기업 정보 시스템에 대한 정보 지원
정보 지원 - 정보 분류 및 인코딩 시스템, 데이터 처리를 위한 기술 체계, 규제 및 참조 정보, 문서 흐름 시스템 등 정보 제공

정보자원을 단일한 정보공간으로 형성하는 정책
다양한 수준에서 정보 자원의 상호 작용을 보장하려면 다음이 필요합니다. a) 현대 정보 기술의 사용 b) 현대 교통 정보 환경 다) 먹는다

컴퓨팅 시스템 사용의 이점
다중 기계 및 다중 프로세서 컴퓨터를 사용하면 다음과 같은 이점을 얻을 수 있습니다. 1) 생산성 및 속도 향상

통신 장비 및 통신 장비
통신 기술은 경영 활동의 주요 기능 중 하나를 제공합니다. 즉, 경영 시스템 내에서 정보를 전송하고 외부 환경과 데이터를 교환하는 것입니다.

운영 체제(OS). OS 기술
시스템 프로그램 중에서 운영체제(OS)는 특별한 위치를 차지한다. 운영 체제(OS)는 관리하는 프로그램의 집합으로 이해됩니다.

기업 정보 시스템의 OS Unix 및 구조적 솔루션. 모빌리티 컨셉
Unix OS의 개발은 1968년 Bell Laboratories에서 시작되었습니다. Main Frame용 다중 사용자 32비트 Unix OS가 제안되었습니다. 1976년에 AT&T(B를 포함)

컴퓨터 네트워크의 개념과 그 특성
컴퓨터 네트워크는 컴퓨팅 리소스를 효율적으로 사용하기 위해 데이터 전송 채널로 상호 연결된 지리적으로 분산된 컴퓨터의 복합체입니다. 실행할 수 있음

컴퓨터 네트워크의 구성
컴퓨터 네트워크에는 하드웨어, 소프트웨어 및 정보 도구가 포함됩니다. 즉, 컴퓨터 네트워크는 하드웨어와 소프트웨어가 지역 전체에 분산되어 있는 시스템으로 간주할 수 있습니다.

컴퓨터 네트워크 아키텍처
일반적으로 컴퓨터 네트워크의 아키텍처는 컴퓨터 네트워크의 물리적 구성(네트워크 토폴로지)과 논리적 수준의 네트워크 구성이라는 두 가지 관점에서 고려할 수 있습니다.

전용서버를 갖춘 컴퓨터 네트워크와 그 특징
클라이언트-서버는 장치가 클라이언트이거나 서버인 네트워크 아키텍처입니다. 클라이언트는 요청하는 머신(보통 PC)이고, 서버는 응답하는 머신입니다.

글로벌 컴퓨터 네트워크의 구조
글로벌 네트워크(WAN, 광역 네트워크)는 광대역 채널을 갖춘 시스템이며 이를 통해 장거리에 있는 컴퓨터 간의 상호 작용을 구성할 수 있습니다. 이상적으로는 글로벌 컴퓨터

컴퓨터 네트워크의 확장성
확장성 – 네트워크 리소스와 가입자를 늘리는 능력입니다. 전용 서버가 있는 컴퓨터 네트워크에서는 워크스테이션이 전용 서버에 연결되고, 서버는 차례로 그룹화됩니다.

인터넷 프로토콜
이 경우 프로토콜은 비유적으로 말하면 컴퓨터가 네트워크에서 작업할 때 데이터를 교환하는 데 사용하는 "언어"입니다. 네트워크상의 여러 컴퓨터가 통신하려면 서로 통신해야 합니다.

인터넷 주소 지정
인터넷은 IP 프로토콜 사용과 데이터 패킷 라우팅을 기반으로 구축된 상호 연결된 컴퓨터 네트워크의 세계적인 시스템입니다. 인터넷은 글로벌 정보 공간을 형성하여 다음과 같은 서비스를 제공합니다.

확장성은 컴퓨팅 리소스가 추가될 때 지원되는 사용자 수, 응답 속도, 전체 성능 등과 같은 시스템 특성의 예측 가능한 증가를 제공하는 컴퓨팅 시스템의 속성입니다. DBMS 서버의 경우 수직형과 수평형의 두 가지 확장 방법을 고려할 수 있습니다(그림 2).

수평적 확장을 통해 DBMS 서버의 수가 증가하고, 서로 투명하게 통신할 수 있어 전체 시스템 부하를 공유할 수 있습니다. 이 솔루션은 느슨하게 결합된 아키텍처와 분산 데이터베이스에 대한 지원이 증가함에 따라 점점 더 대중화될 가능성이 높지만 관리가 어려운 경향이 있습니다.

수직적 확장에는 별도의 DBMS 서버의 성능을 높이는 것이 포함되며 하드웨어(프로세서, 디스크)를 더 빠른 것으로 교체하거나 추가 노드를 추가하여 달성됩니다. 좋은 예는 대칭형 다중 프로세서(SMP) 플랫폼의 프로세서 수가 증가하는 것입니다. 이 경우 서버 소프트웨어를 변경하면 안 됩니다(특히 추가 모듈 구매가 필요하지 않음). 이렇게 하면 관리가 복잡해지고 시스템 동작의 예측 가능성이 낮아질 수 있습니다. 어떤 확장 방법을 사용하든 관계없이 서버 프로그램이 사용 가능한 컴퓨팅 리소스를 얼마나 완전하게 사용하는지에 따라 이득이 결정됩니다. 추가 평가에서는 분석가에 따르면 현대 컴퓨터 시장에서 가장 큰 성장을 경험하고 있는 수직적 확장을 고려할 것입니다.

확장성 속성은 두 가지 주요 이유와 관련이 있습니다. 우선, 현대의 비즈니스 상황은 너무 빨리 변화하여 이미 오래된 데이터에 대한 포괄적이고 장기간의 분석이 필요한 장기 계획을 세우는 것이 불가능합니다. 심지어 이를 감당할 수 있는 조직에게도 불가능합니다. 그 대가로 정보 시스템의 힘을 점진적으로, 단계적으로 증가시키는 전략이 나옵니다. 반면, 기술의 변화는 점점 더 많은 새로운 솔루션의 출현과 하드웨어 가격의 하락으로 이어지며, 이는 잠재적으로 정보 시스템의 아키텍처를 더욱 유연하게 만듭니다. 동시에, 지금까지 표준을 준수하려는 노력이 좁은 시장 부문에서만 조정되었지만, 다양한 제조업체의 소프트웨어 및 하드웨어 제품의 상호 운용성과 개방성이 확대되고 있습니다. 이러한 요소를 고려하지 않으면 소비자는 충분히 개방적이지 않거나 가능성이 없는 것으로 입증된 기술에 투자된 자금을 동결하지 않고서는 신기술을 활용할 수 없습니다. 데이터 저장 및 처리 분야에서는 DBMS와 서버 모두 확장성이 필요합니다. 현재 주요 확장성 매개변수는 다음과 같습니다.

• 다중 처리 지원;
• 건축적 유연성.

다중 프로세서 시스템

수직 확장의 경우 대칭형 다중 프로세서(SMP) 시스템이 점점 더 많이 사용되고 있습니다. 이 경우 플랫폼을 변경할 필요가 없기 때문입니다. 운영 체제, 하드웨어 및 관리 기술. 이를 위해 MPP(대량 병렬 처리) 시스템을 사용하는 것도 가능하지만 지금까지는 계산 작업과 같은 특수 작업으로만 사용이 제한됩니다. 병렬 아키텍처를 사용하는 DBMS 서버를 평가할 때 아키텍처 확장성의 두 가지 주요 특성인 적절성과 투명성에 주의하는 것이 좋습니다.

적절성 속성을 위해서는 서버 아키텍처가 추가 소프트웨어 모듈은 물론 재설치나 구성의 중요한 변경 없이 1개 또는 10개의 프로세서를 동일하게 지원해야 합니다. 이러한 아키텍처는 단일 프로세서 시스템과 해결되는 작업의 복잡성이 증가함에 따라 여러 프로세서 또는 다중(MPP) 프로세서 모두에서 똑같이 유용하고 효과적입니다. 일반적으로 소비자는 새로운 소프트웨어 옵션을 구입하거나 배울 필요가 없습니다.

서버 아키텍처에 투명성을 제공하면 애플리케이션에서 하드웨어 구성 변경 사항을 숨길 수 있습니다. 응용 소프트웨어 시스템의 이식성을 보장합니다. 특히, 긴밀하게 결합된 다중 프로세서 아키텍처에서는 애플리케이션이 공유 메모리 세그먼트를 통해 서버와 통신할 수 있는 반면, 느슨하게 결합된 다중 서버 시스템(클러스터)에서는 이러한 목적으로 메시지 메커니즘을 사용할 수 있습니다. 애플리케이션은 하드웨어 아키텍처의 구현 기능을 고려해서는 안 됩니다. 데이터 조작 방법과 데이터베이스 액세스를 위한 소프트웨어 인터페이스는 동일하고 동일하게 효과적이어야 합니다.

다중 처리에 대한 고품질 지원을 위해서는 데이터베이스 서버가 제공될 많은 쿼리의 실행을 독립적으로 예약할 수 있어야 하며, 이를 통해 서버 작업 간에 사용 가능한 컴퓨팅 리소스를 가장 완벽하게 분할할 수 있습니다. 요청은 여러 작업에 의해 순차적으로 처리되거나 하위 작업으로 나누어 병렬로 실행될 수 있습니다(그림 3). 이 메커니즘을 적절하게 구현하면 요청 유형 및 애플리케이션에 관계없이 이점을 제공하므로 후자가 더 최적입니다. 처리 효율성은 스케줄러 작업에서 고려하는 작업의 세분성 수준에 따라 크게 영향을 받습니다. 예를 들어, 개별 SQL 쿼리 수준에서 대략적인 세분화를 사용하면 컴퓨터 시스템 리소스(프로세서, 메모리, 디스크) 분할이 최적이 아닙니다. 작업은 유휴 상태가 되며 필요한 I/O 작업이 끝날 때까지 기다립니다. SQL 쿼리를 완료하려면 적어도 대기열에 상당한 계산 작업이 필요한 다른 쿼리가 있었습니다. 더 세밀하게 세분화하면 단일 SQL 쿼리 내에서도 리소스 분할이 발생하며, 이는 여러 쿼리가 병렬로 처리될 때 더욱 분명해집니다. 스케줄러를 사용하면 실제 데이터베이스 유지 관리 작업을 해결하는 데 대규모 시스템 리소스가 사용되며 가동 중지 시간이 최소화됩니다.

아키텍처 유연성

이동성 수준, 표준 지원, 병렬성 및 기타 유용한 품질에 관계없이 실질적인 아키텍처 제한이 내장된 DBMS의 성능은 자유롭게 향상될 수 없습니다. 데이터베이스 개체 및 메모리 버퍼의 수와 크기, 동시 연결 수, 호출 프로시저 및 하위 쿼리의 재귀 깊이 또는 데이터베이스 트리거 실행에 대한 문서화된 또는 실제 제한 사항은 다음과 같은 DBMS 적용 가능성에 대한 동일한 제한 사항입니다. , 예를 들어 여러 컴퓨팅 플랫폼으로 이전하는 것이 불가능합니다. 데이터베이스 쿼리의 복잡성을 제한하는 매개변수, 특히 동적 버퍼의 크기와 재귀 호출을 위한 스택 크기는 동적으로 구성 가능해야 하며 재구성을 위해 시스템을 중지할 필요가 없습니다. DBMS 내부의 한계로 인해 기대에 부응할 수 없다면 강력한 새 서버를 구입할 의미가 없습니다.

일반적으로 병목 현상은 데이터베이스 서버 프로그램의 특성을 동적으로 조정할 수 없다는 것입니다. 소비된 메모리 양, 사용 중인 프로세서 수, 병렬 작업 스레드 수(실제 스레드, 운영 체제 프로세스 또는 가상 프로세서) 및 데이터베이스 테이블 조각 수와 같은 실시간 매개변수를 결정하는 기능 시스템을 중지하고 다시 시작하지 않고 인덱스를 물리적 디스크에 배포하는 것은 최신 애플리케이션의 본질에서 발생하는 요구 사항입니다. 이상적으로는 이러한 각 매개변수가 사용자별 제한 내에서 동적으로 변경될 수 있습니다.