가상화된 데이터 센터 설계

소개

사용자 관점의 정보 시스템은 GOST RV 51987에 잘 정의되어 있습니다. 즉, "자동화 시스템으로, 그 결과 후속 사용을 위한 출력 정보가 ​​표시됩니다." 내부 구조를 고려하면 본질적으로 모든 IS는 코드로 구현된 상호 연결된 알고리즘 시스템입니다. Turing-Church 이론의 넓은 의미에서 알고리즘(또는 IS)은 입력 데이터 세트를 출력 데이터 세트로 변환합니다.
입력 데이터의 변환은 정보 시스템의 존재 의미라고 말할 수도 있습니다. 따라서 IS와 전체 IS 복합체의 값은 입출력 데이터의 값을 통해 결정된다.
이를 바탕으로 설계는 데이터 중심으로 시작되어야 하며 데이터의 구조와 중요성에 맞게 아키텍처와 방법을 조정해야 합니다.

저장된 데이터
설계 준비의 핵심 단계는 처리 및 저장을 위해 계획된 모든 데이터 세트의 특성을 파악하는 것입니다. 이러한 특성은 다음과 같습니다.
- 데이터 볼륨;
— 데이터 수명주기에 대한 정보(새로운 데이터의 증가, 수명, 오래된 데이터 처리)
— 관점에서 데이터 분류 재무 지표(예: 지난 한 시간 동안의 데이터 손실 비용)와 함께 회사의 핵심 비즈니스(기밀성, 무결성, 가용성의 3요소)에 미치는 영향
— 데이터 처리 지리(처리 시스템의 물리적 위치)
— 각 데이터 클래스에 대한 규제 요구 사항(예: 연방법-152, PCI DSS).

정보 시스템

데이터는 정보 시스템에 의해 저장될 뿐만 아니라 처리(변환)됩니다. 데이터 특성을 얻은 후 다음 단계는 네 가지 유형의 리소스에 대한 기존 단위의 정보 시스템, 아키텍처 기능, 상호 의존성 및 인프라 요구 사항에 대한 가장 완전한 목록을 작성하는 것입니다.
— 프로세서 컴퓨팅 성능;
— RAM 용량
— 데이터 저장 시스템의 용량 및 성능에 대한 요구 사항;
— 데이터 전송 네트워크에 대한 요구 사항(외부 채널, IS 구성 요소 간 채널).
이 경우 IS의 일부로 각 서비스/마이크로서비스에 대한 요구 사항이 있어야 합니다.
이와 별도로, 올바른 설계를 위해서는 IS 가동 중지 시간 비용(시간당 루블)의 형태로 IS가 회사의 핵심 비즈니스에 미치는 영향에 대한 데이터 가용성이 필수라는 점에 유의할 필요가 있습니다.

위협 모델

데이터/서비스를 보호하기 위해 계획된 공식적인 위협 모델이 있어야 합니다. 또한 위협 모델에는 기밀성 측면뿐만 아니라 무결성 및 가용성 측면도 포함됩니다. 저것들. 예를 들어:
— 물리적 서버에 장애가 발생했습니다.
— 랙 상단형 스위치 오류.
— 데이터 센터 간의 광통신 채널 중단;
— 운영 중인 전체 스토리지 시스템에 오류가 발생했습니다.
경우에 따라 위협 모델은 인프라 구성 요소뿐만 아니라 데이터 구조의 논리적 파괴로 인한 DBMS 오류와 같은 특정 정보 시스템 또는 해당 구성 요소에 대해서도 작성됩니다.
설명되지 않은 위협으로부터 보호하기 위해 프로젝트 내에서 모든 결정은 불필요합니다.

규제 요구 사항

처리 중인 데이터가 규제 기관에서 정한 특별 규칙의 적용을 받는 경우 데이터 세트 및 처리/저장 규칙에 대한 정보가 필요합니다.

RPO/RTO 목표

모든 유형의 보호를 설계하려면 설명된 각 위협에 대한 대상 데이터 손실 지표와 대상 서비스 복구 시간이 필요합니다.
이상적으로 RPO와 RTO에는 단위 시간당 데이터 손실 및 가동 중지 시간과 관련된 비용이 있어야 합니다.

자원 풀로 분할

모든 초기 입력 정보를 수집한 후 첫 번째 단계는 위협 모델 및 규제 요구 사항에 따라 데이터 세트와 IP를 풀로 그룹화하는 것입니다. 다양한 풀의 분할 유형은 시스템 소프트웨어 수준에서 프로그래밍 방식으로 또는 물리적으로 결정됩니다.
예 :
— 개인 데이터를 처리하는 회로는 다른 시스템과 물리적으로 완전히 분리되어 있습니다.
— 백업은 별도의 스토리지 시스템에 저장됩니다.

이 경우 풀은 불완전하게 독립적일 수 있습니다. 예를 들어 단일 데이터 저장 풀과 단일 데이터 전송 리소스 풀을 사용하는 두 개의 컴퓨팅 리소스 풀(프로세서 전력 + RAM)이 정의됩니다.

처리 능력

요약하자면, 가상화된 데이터 센터의 처리 능력 요구 사항은 가상 프로세서(vCPU) 수와 물리적 프로세서(pCPU)에서의 통합 비율로 측정됩니다. 이 특별한 경우 1 pCPU = 1 물리적 프로세서 코어(하이퍼스레딩 제외)입니다. vCPU 수는 정의된 모든 리소스 풀에서 합산됩니다(각 리소스 풀은 고유한 통합 요소를 가질 수 있음).
로드된 시스템의 통합 계수는 기존 인프라를 기반으로 하거나 파일럿 설치 및 로드 테스트를 통해 경험적으로 얻습니다. 언로드된 시스템의 경우 "모범 사례"가 사용됩니다. 특히 VMware는 평균 비율을 8:1로 언급합니다.

수술 기억

총 RAM 요구 사항은 간단한 합산으로 구합니다. RAM 초과 구독을 사용하는 것은 권장되지 않습니다.

스토리지 리소스

스토리지 요구 사항은 용량과 성능별로 모든 풀을 간단히 합산하여 얻을 수 있습니다.
성능 요구 사항은 평균 읽기/쓰기 비율과 필요한 경우 최대 응답 대기 시간을 결합한 IOPS로 표현됩니다.
특정 풀 또는 시스템에 대한 QoS(서비스 품질) 요구 사항은 별도로 지정해야 합니다.

데이터 네트워크 리소스

데이터 네트워크 요구 사항은 모든 대역폭 풀을 합산하여 얻을 수 있습니다.
특정 풀 또는 시스템에 대한 QoS(서비스 품질) 및 RTT(지연 시간) 요구 사항은 별도로 지정해야 합니다.
데이터 네트워크 리소스에 대한 요구 사항의 일부로 네트워크 트래픽의 격리 및/또는 암호화 요구 사항과 기본 메커니즘(802.1q, IPSec 등)도 표시됩니다.

아키텍처 선택

이 가이드에서는 x86 아키텍처와 100% 서버 가상화 이외의 선택에 대해서는 논의하지 않습니다. 따라서 컴퓨팅 하위 시스템 아키텍처의 선택은 서버 가상화 플랫폼, 서버 폼 팩터 및 일반 서버 구성 요구 사항의 선택에 따라 결정됩니다.

선택의 핵심 포인트는 데이터 처리, 저장 및 전송 기능을 분리하거나 수렴하는 기능을 갖춘 고전적인 접근 방식을 사용한다는 확신입니다.

고전 건축 데이터 저장 및 전송을 위해 지능형 외부 하위 시스템을 사용하는 반면, 서버는 물리적 리소스의 공통 풀에 처리 능력과 RAM만 제공합니다. 극단적인 경우 서버는 자체 디스크는 물론 시스템 식별자조차 갖지 않는 완전히 익명이 됩니다. 이 경우 OS 또는 하이퍼바이저는 내장 플래시 미디어 또는 외부 데이터 스토리지 시스템(SAN에서 부팅)에서 로드됩니다.
클래식 아키텍처 프레임워크 내에서 블레이드와 랙 간의 선택은 주로 다음 원칙에 따라 이루어집니다.
— 비용 효율적입니다(평균적으로 랙 마운트 서버가 더 저렴함).
— 계산 밀도(블레이드의 경우 더 높음)
— 에너지 소비 및 열 방출(블레이드의 단위당 특정 단위가 더 높음)
— 확장성 및 제어성(블레이드는 일반적으로 대규모 설치에 더 적은 노력이 필요함)
- 확장 카드 사용(블레이드의 경우 선택이 매우 제한됨)
융합 아키텍처 (또한 ~으로 알려진 하이퍼컨버지드)에는 데이터 처리 및 저장 기능이 결합되어 로컬 서버 디스크를 사용하게 되고 결과적으로 기존 블레이드 폼 팩터가 포기됩니다. 통합 시스템의 경우 랙 서버 또는 클러스터 시스템이 사용되며 여러 블레이드 서버와 로컬 디스크를 단일 케이스에 결합합니다.

CPU / 메모리

구성을 올바르게 계산하려면 환경 또는 각 독립 클러스터의 로드 유형을 이해해야 합니다.
CPU 바인딩 – 프로세서 성능으로 인해 성능이 제한되는 환경. RAM을 추가해도 성능(서버당 VM 수)에는 아무런 변화가 없습니다.
메모리 바운드 – RAM으로 인해 환경이 제한됩니다. 서버에 RAM이 많을수록 서버에서 더 많은 VM을 실행할 수 있습니다.
GB/MHz(GB/pCPU) – 이 특정 로드에 의한 RAM 및 프로세서 전력 소비의 평균 비율입니다. 특정 성능에 필요한 메모리 양을 계산하는 데 사용할 수 있으며 그 반대의 경우도 마찬가지입니다.

서버 구성 계산

먼저, 모든 유형의 로드를 결정하고 서로 다른 컴퓨팅 풀을 서로 다른 클러스터로 결합하거나 분할할지 결정해야 합니다.
다음으로 정의된 각 클러스터에 대해 미리 알려진 부하에서 GB/MHz 비율이 결정됩니다. 로드를 미리 알 수 없지만 프로세서 전력 사용률 수준을 대략적으로 이해하고 있는 경우 표준 vCPU:pCPU 비율을 사용하여 풀 요구 사항을 물리적 요구 사항으로 변환할 수 있습니다.

각 클러스터에 대해 vCPU 풀 요구 사항의 합계를 계수로 나눕니다.
vCPUsum / vCPU:pCPU = pCPUsum – 필요한 물리적 장치 수입니다. 코어
pCPUsum / 1.25 = pCPUht – 하이퍼 스레딩에 맞게 조정된 코어 수
190개 코어/3.5TB RAM이 있는 클러스터를 계산해야 한다고 가정해 보겠습니다. 동시에 우리는 프로세서 성능의 50%와 RAM의 75%의 목표 로드를 수용합니다.

pCPU
190
CPU 활용도
50%

멤
3500
메모리 유틸리티
75%

소켓
핵심
서비스/CPU
서버 메모리
서버/메모리

2
6
25,3
128
36,5

2
8
19,0
192
24,3

2
10
15,2
256
18,2

2
14
10,9
384
12,2

2
18
8,4
512
9,1

이 경우 항상 가장 가까운 정수로 반올림합니다(=ROUNDUP(A1;0)).
표에서 여러 서버 구성이 대상 지표에 대해 균형을 이루고 있음이 분명해졌습니다.
— 26개 서버 2*6c / 192GB
— 19개 서버 2*10c / 256GB
— 10개 서버 2*18c / 512GB

그런 다음 열 패키지 및 사용 가능한 냉각, 이미 사용된 서버 또는 비용과 같은 추가 요소를 기반으로 이러한 구성을 선택해야 합니다.

서버 구성 선택의 특징

광범위한 VM. 광범위한 VM(1개 NUMA 노드 이상)을 호스팅해야 하는 경우 가능하면 이러한 VM이 NUMA 노드 내에 유지되도록 허용하는 구성을 갖춘 서버를 선택하는 것이 좋습니다. 와이드 VM의 수가 많으면 클러스터 리소스가 조각화될 위험이 있으며, 이 경우 와이드 VM을 최대한 조밀하게 배치할 수 있는 서버를 선택합니다.

단일 장애 도메인 크기.

서버 크기 선택 역시 단일 장애 도메인 최소화 원칙을 기반으로 합니다. 예를 들어 다음 중 하나를 선택할 때:
— 3 x 4*10c / 512GB
— 6 x 2*10c / 256GB
다른 모든 조건이 동일하다면 두 번째 옵션을 선택해야 합니다. 한 서버가 실패하거나 유지 관리되는 경우 클러스터 리소스의 33%가 아니라 17%가 손실되기 때문입니다. 마찬가지로 사고로 영향을 받는 VM과 IS의 수도 절반으로 줄어든다.

성능을 기반으로 클래식 스토리지 시스템 계산

클래식 스토리지 시스템은 항상 운영 캐시 및 운영 최적화의 영향을 제외하고 최악의 시나리오를 사용하여 계산됩니다.
기본 성능 지표로 디스크(IOPSdisk)에서 기계적 성능을 가져옵니다.
– 7.2k – 75IOPS
– 10k – 125IOPS
– 15k – 175IOPS

그런 다음 디스크 풀의 디스크 수는 다음 공식을 사용하여 계산됩니다. = 총IOPS * ( RW + (1 –RW) * RAIDPen) / IOPSdisk. 어디:
- 총IOPS – 디스크 풀에서 필요한 총 IOPS 성능
- RW – 읽기 작업의 비율
- RAID 펜 – 선택한 RAID 레벨에 대한 RAID 페널티

여기에서 장치 RAID 및 RAID 페널티에 대해 자세히 알아보세요. 저장 성능. 1부. и 저장 성능. 두 번째 부분. и 저장 성능. 3부

결과적인 디스크 수에 따라 다중 레벨 스토리지 옵션을 포함하여 스토리지 용량 요구 사항을 충족하는 가능한 옵션이 계산됩니다.
SSD를 스토리지 계층으로 사용하는 시스템의 계산은 별도로 고려됩니다.
Flash Cache를 사용한 계산 시스템의 특징

플래시 캐시 – 플래시 메모리를 2차 캐시로 사용하기 위한 모든 독점 기술의 공통 이름입니다. 플래시 캐시를 사용할 때 스토리지 시스템은 일반적으로 자기 디스크에서 안정적인 로드를 제공하도록 계산되며 최대 로드는 캐시에 의해 제공됩니다.
이 경우 로드 프로필과 스토리지 볼륨 블록에 대한 액세스 지역화 정도를 이해해야 합니다. 플래시 캐시는 고도로 지역화된 쿼리가 포함된 워크로드를 위한 기술이며 균일하게 로드되는 볼륨(예: 분석 시스템)에는 사실상 적용할 수 없습니다.

중저가형 하이브리드 시스템 계산

중하층의 하이브리드 시스템은 일정에 따라 레벨 간에 데이터가 이동하는 다단계 스토리지를 사용합니다. 동시에 최고의 모델의 다중 레벨 저장 블록 크기는 256MB입니다. 이러한 기능을 사용하면 많은 사람들이 잘못 믿고 있는 것처럼 계층형 스토리지 기술을 생산성 향상을 위한 기술로 간주할 수 없습니다. 중저급 시스템의 다단계 스토리지는 로드 불균일이 뚜렷한 시스템의 스토리지 비용을 최적화하기 위한 기술입니다.

계층형 스토리지의 경우 최상위 계층의 성능이 먼저 계산되는 반면, 스토리지의 최하위 계층은 누락된 스토리지 용량에만 기여하는 것으로 간주됩니다. 하이브리드 다중 계층 시스템의 경우 하위 수준에서 갑자기 발열되는 데이터에 대한 성능 저하를 보상하기 위해 다중 계층 풀에 플래시 캐시 기술을 사용하는 것이 필수입니다.

계층화된 디스크 풀에서 SSD 사용

다중 레벨 디스크 풀에서 SSD를 사용하는 방법은 해당 제조업체의 특정 플래시 캐시 알고리즘 구현에 따라 다릅니다.
SSD 수준의 디스크 풀에 대한 스토리지 정책의 일반적인 관행은 SSD 우선입니다.
읽기 전용 플래시 캐시. 읽기 전용 플래시 캐시의 경우 SSD의 스토리지 계층에는 캐시에 관계없이 쓰기가 상당히 현지화되어 있습니다.
읽기/쓰기 플래시 캐시. 플래시 캐시의 경우 쓰기 캐시 크기가 먼저 최대 캐시 크기로 설정되고 SSD 스토리지 계층은 캐시 크기가 전체 지역화된 워크로드를 처리하기에 부족한 경우에만 나타납니다.
SSD 및 캐시 성능 계산은 제조업체의 권장 사항에 따라 매번 이루어지지만 항상 최악의 경우를 기준으로 합니다.

출처 : habr.com