하이퍼컨버지드 솔루션 AERODISK vAIR. 기본은 ARDFS 파일 시스템입니다.

안녕하세요, 하브르 독자 여러분. 이 기사를 통해 우리는 우리가 개발한 하이퍼컨버지드 시스템 AERODISK vAIR에 대해 이야기하는 시리즈를 시작합니다. 처음에 우리는 첫 번째 기사에서 모든 것에 대해 모든 것을 말하고 싶었지만 시스템이 상당히 복잡하므로 코끼리를 부분적으로 먹을 것입니다.

시스템 생성 역사부터 이야기를 시작하고, vAIR의 기반이 되는 ARDFS 파일 시스템을 살펴보고, 러시아 시장에서 이 솔루션의 포지셔닝에 대해서도 조금 이야기해 보겠습니다.

향후 기사에서는 다양한 아키텍처 구성 요소(클러스터, 하이퍼바이저, 로드 밸런서, 모니터링 시스템 등), 구성 프로세스, 라이센스 문제 제기, 충돌 테스트를 별도로 표시하고 로드 테스트 및 사이징. 또한 vAIR의 커뮤니티 버전에 대한 별도의 기사를 작성할 것입니다.

Aerodisk는 스토리지 시스템에 관한 이야기인가요? 아니면 애초에 우리가 하이퍼컨버전스를 시작한 이유는 무엇일까요?

처음에는 우리만의 하이퍼컨버전스를 만들겠다는 아이디어가 2010년쯤에 떠올랐습니다. 당시 시장에는 Aerodisk나 유사한 솔루션(상용 박스형 하이퍼컨버지드 시스템)이 없었습니다. 우리의 임무는 다음과 같습니다. 이더넷 프로토콜을 통한 상호 연결로 통합된 로컬 디스크가 있는 서버 세트에서 확장 스토리지를 생성하고 거기에서 가상 머신과 소프트웨어 네트워크를 시작해야 했습니다. 이 모든 것은 스토리지 시스템 없이 구현되어야 했습니다(스토리지 시스템과 하드웨어를 구입할 돈이 없었고 우리는 아직 자체 스토리지 시스템을 발명하지 않았기 때문입니다).

우리는 많은 오픈 소스 솔루션을 시도하고 마침내 이 문제를 해결했지만 솔루션은 매우 복잡하고 반복하기 어려웠습니다. 게다가 이 솔루션은 “작동합니까?”라는 범주에 속했습니다. 만지지 마세요! 따라서 그 문제를 해결한 후에는 작업 결과를 본격적인 제품으로 변환하려는 아이디어를 더 이상 개발하지 않았습니다.

그 사건 이후 우리는 이 아이디어에서 멀어졌지만 여전히 이 문제가 완전히 해결 가능하고 그러한 솔루션의 이점이 분명하다는 느낌을 받았습니다. 이후 출시된 해외 업체의 HCI 제품도 이런 느낌을 확증해줬다.

따라서 2016년 중반에 우리는 완전한 제품을 만드는 과정의 일환으로 이 작업으로 돌아왔습니다. 당시 우리는 아직 투자자들과 어떤 관계도 맺지 않았기 때문에 그리 큰 돈이 아닌 자체 개발 스탠드를 구입해야했습니다. Avito에서 중고 서버와 스위치를 수집한 후 우리는 사업을 시작했습니다.

주요 초기 작업은 비록 단순하지만 이더넷을 통해 상호 연결로 연결된 n번째 클러스터 노드에 가상 블록 형태로 데이터를 자동으로 균등하게 배포할 수 있는 자체 파일 시스템을 만드는 것이었습니다. 동시에 FS는 쉽고 쉽게 확장 가능해야 하며 인접한 시스템으로부터 독립적이어야 합니다. "단순한 저장 시설"의 형태로 vAIR로부터 소외됩니다.

최초의 vAIR 개념

우리는 이미 많은 프로젝트 경험을 갖고 있었기 때문에 자체 개발을 위해 확장된 스토리지(ceph, gluster, Luster 등)를 구성하기 위해 기성 오픈 소스 솔루션의 사용을 의도적으로 포기했습니다. 물론 이러한 솔루션 자체는 훌륭하며 Aerodisk를 작업하기 전에 우리는 이들 솔루션을 사용하여 두 개 이상의 통합 프로젝트를 구현했습니다. 그러나 한 고객을 위한 특정 작업을 구현하고 직원을 교육하고 대규모 공급업체의 지원을 구매하는 것과 다양한 작업에 사용할 수 있는 쉽게 복제할 수 있는 제품을 만드는 것은 전혀 다른 문제입니다. 공급업체는 우리 자신에 대해 알지 못할 수도 있습니다. 두 번째 목적으로는 기존 오픈소스 제품이 우리에게 적합하지 않아 분산 파일 시스템을 직접 만들기로 결정했습니다.
XNUMX년 후, 여러 개발자(vAIR 작업과 클래식 엔진 스토리지 시스템 작업을 결합한)가 특정 결과를 달성했습니다.

2018년까지 우리는 간단한 파일 시스템을 작성하고 필요한 하드웨어로 이를 보완했습니다. 시스템은 서로 다른 서버의 물리적(로컬) 디스크를 내부 상호 연결을 통해 하나의 플랫 풀로 결합하고 이를 가상 블록으로 "절단"한 다음 가상 블록이 생성된 가상 블록에서 다양한 수준의 내결함성을 가진 블록 장치를 생성했습니다. KVM 하이퍼바이저 차량을 사용하여 실행됩니다.

우리는 파일 시스템 이름에 크게 신경 쓰지 않고 간결하게 ARDFS라고 불렀습니다(무슨 뜻인지 추측해 보세요).

이번 프로토타입은 보기에도 좋아 보였고(물론 아직 시각적인 디자인도 없었음) 성능이나 스케일링 측면에서도 좋은 결과를 보여줬습니다. 첫 번째 실제 결과를 얻은 후 우리는 본격적인 개발 환경과 vAIR만을 다루는 별도의 팀을 구성하여 이 프로젝트를 시작했습니다.

그 무렵에는 솔루션의 일반적인 아키텍처가 성숙해졌으며 아직 큰 변화가 발생하지 않았습니다.

ARDFS 파일 시스템 살펴보기

ARDFS는 전체 클러스터에 분산된 내결함성 데이터 스토리지를 제공하는 vAIR의 기반입니다. ARDFS의 유일한 특징 중 하나는 메타데이터 및 관리를 위해 추가 전용 서버를 사용하지 않는다는 것입니다. 이는 원래 솔루션 구성을 단순화하고 신뢰성을 높이기 위해 고안되었습니다.

저장구조

클러스터의 모든 노드 내에서 ARDFS는 사용 가능한 모든 디스크 공간에서 논리 풀을 구성합니다. 풀은 아직 데이터나 형식화된 공간이 아니라 단순히 마크업이라는 점을 이해하는 것이 중요합니다. vAIR가 설치된 모든 노드는 클러스터에 추가되면 자동으로 공유 ARDFS 풀에 추가되고 디스크 리소스는 자동으로 전체 클러스터에서 공유됩니다(향후 데이터 저장에 사용할 수 있음). 이 접근 방식을 사용하면 이미 실행 중인 시스템에 심각한 영향을 주지 않고 즉시 노드를 추가하고 제거할 수 있습니다. 저것들. 시스템은 필요한 경우 클러스터에 노드를 추가하거나 제거하여 "브릭 단위로" 확장하기가 매우 쉽습니다.

가상 디스크(가상 머신용 스토리지 개체)는 4MB 크기의 가상 블록으로 구축된 ARDFS 풀 위에 추가됩니다. 가상 디스크는 데이터를 직접 저장합니다. 내결함성 체계는 가상 디스크 수준에서도 설정됩니다.

이미 짐작하셨겠지만 디스크 하위 시스템의 내결함성을 위해 RAID(Redundant array of independent Disks) 개념을 사용하지 않고 RAIN(Redundant array of independent Nodes) 개념을 사용합니다. 저것들. 내결함성은 디스크가 아닌 노드를 기반으로 측정, 자동화 및 관리됩니다. 물론 디스크는 저장소 개체이기도 하며 다른 모든 것과 마찬가지로 모니터링되며 로컬 하드웨어 RAID 조립을 포함하여 모든 표준 작업을 수행할 수 있지만 클러스터는 특히 노드에서 작동합니다.

실제로 RAID를 원하는 상황(예: 소규모 클러스터에서 여러 오류를 지원하는 시나리오)에서는 로컬 RAID 컨트롤러를 사용하고 확장된 스토리지와 RAIN 아키텍처를 구축하는 것을 방해할 수 없습니다. 이 시나리오는 매우 실제적이고 우리가 지원하므로 vAIR 사용에 대한 일반적인 시나리오에 대한 기사에서 이에 대해 설명하겠습니다.

스토리지 내결함성 체계

vAIR의 가상 디스크에는 두 가지 내결함성 체계가 있을 수 있습니다.

1) 복제 요소 또는 단순한 복제 - 이 내결함성 방법은 막대기와 밧줄만큼 간단합니다. 동기 복제는 2(클러스터당 복사본 2개) 또는 3(각각 3개 복사본) 요소로 노드 간에 수행됩니다. RF-2를 사용하면 가상 디스크가 클러스터에 있는 한 노드의 오류를 견딜 수 있지만 유용한 볼륨의 절반을 "먹습니다". RF-3은 클러스터에 있는 2개의 노드의 오류를 견딜 수 있지만 2/3를 예약합니다. 필요에 따라 유용한 볼륨을 제공합니다. 이 구성표는 RAID-1과 매우 유사합니다. 즉, RF-2로 구성된 가상 디스크는 클러스터의 한 노드 오류에 대한 저항력이 있습니다. 이 경우 데이터에 문제가 없으며 I/O도 중지되지 않습니다. 손상된 노드가 다시 서비스 상태로 돌아오면 자동 데이터 복구/동기화가 시작됩니다.

다음은 정상 모드와 장애 상황에서 RF-2 및 RF-3 데이터 분포의 예입니다.

우리는 8개의 vAIR 노드에서 실행되는 4MB의 고유한(유용한) 데이터 용량을 갖춘 가상 머신을 보유하고 있습니다. 실제로는 그렇게 작은 볼륨이 없을 것임이 분명하지만 ARDFS 작업 논리를 반영하는 체계의 경우 이 예가 가장 이해하기 쉽습니다. AB는 고유한 가상 머신 데이터를 포함하는 4MB 가상 블록입니다. RF-2는 각각 A1+A2 및 B1+B2 블록의 두 복사본을 생성합니다. 이러한 블록은 노드 전체에 "배치"되어 동일한 노드에서 동일한 데이터가 교차하는 것을 방지합니다. 즉, 복사본 A1은 복사본 A2와 동일한 노드에 위치하지 않습니다. B1, B2도 마찬가지다.

노드 중 하나에 오류가 발생하면(예: B3의 복사본이 포함된 노드 번호 1) 해당 복사본(즉, B2의 복사본)이 없는 노드에서 이 복사본이 자동으로 활성화됩니다.

따라서 가상 디스크(및 그에 따른 VM)는 RF-2 구성표에서 한 노드의 오류가 발생해도 쉽게 살아남을 수 있습니다.

복제 방식은 간단하고 안정적이지만 RAID1과 동일한 문제, 즉 사용 가능한 공간이 부족하다는 문제가 있습니다.

2) 위의 문제를 해결하기 위해 삭제 코딩 또는 삭제 코딩("중복 코딩", "삭제 코딩" 또는 "중복 코드"라고도 함)이 존재합니다. EC는 복제에 비해 디스크 공간 오버헤드가 낮으면서 높은 데이터 가용성을 제공하는 중복 구성표입니다. 이 메커니즘의 작동 원리는 RAID 5, 6, 6P와 유사합니다.

인코딩할 때 EC 프로세스는 EC 구성표에 따라 가상 블록(기본적으로 4MB)을 여러 개의 작은 "데이터 청크"로 나눕니다. 예를 들어 2+1 구성표는 각 4MB 블록을 2개의 2MB 청크로 나눕니다. 다음으로, 이 프로세스는 이전에 분할된 부분 중 하나보다 크지 않은 "데이터 청크"에 대한 "패리티 청크"를 생성합니다. 디코딩할 때 EC는 전체 클러스터에서 "잔존" 데이터를 읽어 누락된 청크를 생성합니다.

예를 들어, 2개의 클러스터 노드에 구현된 1 + 4 EC 구성의 가상 디스크는 RF-2와 동일한 방식으로 클러스터에 있는 한 노드의 장애를 쉽게 견딜 수 있습니다. 이 경우 간접비가 낮아집니다. 특히 RF-2의 유효 용량 계수는 2이고 EC 2+1의 경우 1,5가 됩니다.

더 간단하게 설명하면, 본질은 가상 블록이 2-8(왜 2에서 8인지, 아래 참조) "조각"으로 나누어지고, 이러한 조각에 대해 비슷한 볼륨의 패리티 "조각"이 계산된다는 것입니다.

결과적으로 데이터와 패리티는 클러스터의 모든 노드에 고르게 분산됩니다. 동시에 복제와 마찬가지로 ARDFS는 동일한 데이터(데이터 복사본 및 해당 패리티)가 동일한 노드에 저장되는 것을 방지하는 방식으로 노드 간에 데이터를 자동으로 배포합니다. 데이터와 해당 패리티가 갑자기 장애가 발생한 하나의 스토리지 노드에서 종료된다는 사실입니다.

다음은 동일한 8MB 가상 머신과 4개의 노드가 있지만 EC 2+1 구성표를 사용하는 예입니다.

블록 A와 B는 각각 2MB씩 2개의 조각(1+1이므로 2개), 즉 A1+A2와 B1+B2로 나누어집니다. 복제본과 달리 A4은 A2의 복사본이 아니며 블록 B와 마찬가지로 두 부분으로 나누어진 가상 블록 A입니다. 총 2개의 4MB 세트를 얻습니다. 각 세트에는 2개의 2MB 조각이 포함되어 있습니다. 다음으로, 이러한 각 세트에 대해 패리티는 2개 이하(즉, XNUMXMB)의 볼륨으로 계산되며, 추가로 + XNUMX개 패리티(AP 및 BP)를 얻습니다. 전체적으로 XNUMX×XNUMX 데이터 + XNUMX×XNUMX 패리티가 있습니다.

다음으로, 데이터가 패리티와 교차하지 않도록 조각이 노드 사이에 "배치"됩니다. 저것들. A1과 A2는 AP와 동일한 노드에 있지 않습니다.

한 노드(예: 세 번째 노드)에 장애가 발생하는 경우, 타락한 블록 B1은 노드 2에 저장된 BP 패리티에서 자동으로 복원되고, 장애가 있는 노드에서 활성화됩니다. B 패리티 없음, 즉 BP 조각. 이 예에서는 노드 번호 1입니다.

나는 독자에게 질문이 있다고 확신합니다.

"당신이 설명하는 모든 것은 경쟁사와 오픈 소스 솔루션 모두에서 오랫동안 구현되었습니다. ARDFS에서 EC를 구현하는 것의 차이점은 무엇입니까?"

그리고 ARDFS의 흥미로운 기능이 있을 것입니다.

유연성에 중점을 둔 삭제 코딩

처음에 우리는 상당히 유연한 EC X+Y 체계를 제공했습니다. 여기서 X는 2에서 8까지의 숫자이고 Y는 1에서 8까지의 숫자와 같지만 항상 X보다 작거나 같습니다. 이 체계는 제공됩니다. 유연성을 위해. 가상 블록을 분할하는 데이터 조각(X)의 수를 늘리면 오버헤드 비용을 줄일 수 있습니다. 즉, 사용 가능한 공간을 늘릴 수 있습니다.
패리티 청크(Y) 수를 늘리면 가상 디스크의 안정성이 높아집니다. Y 값이 클수록 클러스터에서 더 많은 노드가 실패할 수 있습니다. 물론 패리티 볼륨을 늘리면 사용 가능한 용량이 줄어들지만 이는 신뢰성에 대한 대가입니다.

EC 회로에 대한 성능의 의존성은 거의 직접적입니다. "부품"이 많을수록 성능은 낮아집니다. 물론 여기서는 균형 잡힌 관점이 필요합니다.

이 접근 방식을 통해 관리자는 최대한의 유연성으로 확장된 스토리지를 구성할 수 있습니다. ARDFS 풀 내에서는 모든 내결함성 체계와 그 조합을 사용할 수 있으며 이는 우리 의견으로는 매우 유용합니다.

다음은 여러 가지(모두 가능한 것은 아님) RF 및 EC 방식을 비교한 표입니다.

표에 따르면 클러스터에서 동시에 최대 8개의 노드 손실을 허용하는 가장 "테리" 조합인 EC 7+7도 표준 복제보다 사용 가능한 공간을 "먹고"(1,875 대 2) 7배 더 나은 보호 기능을 제공합니다. , 이는 이 보호 메커니즘을 더 복잡하지만 제한된 디스크 공간 조건에서 최대 신뢰성을 보장해야 하는 상황에서 훨씬 더 매력적으로 만듭니다. 동시에 X 또는 Y에 대한 모든 "추가"는 추가 성능 오버헤드가 된다는 점을 이해해야 합니다. 따라서 안정성, 절약 및 성능 사이의 삼각 관계에서 매우 신중하게 선택해야 합니다. 이러한 이유로 삭제 코딩 크기 조정에 대한 별도의 기사를 다루겠습니다.

파일 시스템의 신뢰성과 자율성

ARDFS는 클러스터의 모든 노드에서 로컬로 실행되며 전용 이더넷 인터페이스를 통해 자체 수단을 사용하여 이를 동기화합니다. 중요한 점은 ARDFS가 데이터뿐만 아니라 스토리지와 관련된 메타데이터까지 독립적으로 동기화한다는 점이다. ARDFS에서 작업하는 동안 우리는 여러 가지 기존 솔루션을 동시에 연구했으며 많은 솔루션이 외부 분산 DBMS를 사용하여 파일 시스템 메타를 동기화한다는 사실을 발견했습니다. 이는 우리도 동기화에 사용하지만 FS 메타데이터가 아닌 구성만 사용합니다(이와 기타 관련 하위 시스템에 대해) 다음 기사에서).

물론 외부 DBMS를 사용하여 FS 메타데이터를 동기화하는 것은 효과적인 솔루션이지만 ARDFS에 저장된 데이터의 일관성은 외부 DBMS와 그 동작에 따라 달라집니다(그리고 솔직히 말하면 변덕스러운 여자입니다). 우리 의견은 나쁘다. 왜? FS 메타데이터가 손상되면 FS 데이터 자체도 '안녕'이라고 말할 수 있기 때문에 우리는 좀 더 복잡하지만 안정적인 경로를 택하기로 했습니다.

우리는 ARDFS용 메타데이터 동기화 하위 시스템을 직접 만들었으며 인접한 하위 시스템과 완전히 독립적으로 작동합니다. 저것들. 다른 하위 시스템은 ARDFS 데이터를 손상시킬 수 없습니다. 우리 의견으로는 이것이 가장 신뢰할 수 있고 올바른 방법이지만 이것이 실제로 그런지는 시간이 말해 줄 것입니다. 또한 이 접근 방식에는 추가적인 이점이 있습니다. ARDFS는 향후 제품에서 확실히 사용할 확장된 스토리지처럼 vAIR와 독립적으로 사용할 수 있습니다.

결과적으로 우리는 ARDFS를 개발함으로써 용량을 절약하거나 성능을 모두 포기하거나, 합리적인 비용으로 매우 안정적인 스토리지를 만들면서 성능 요구 사항을 줄일 수 있는 선택권을 제공하는 유연하고 안정적인 파일 시스템을 얻었습니다.

간단한 라이선스 정책 및 유연한 제공 모델(앞으로 vAIR은 노드별로 라이선스가 부여되고 소프트웨어 또는 소프트웨어 패키지로 제공됨)과 함께 다양한 고객 요구 사항에 맞게 솔루션을 매우 정확하게 맞춤화할 수 있습니다. 그러면 이 균형을 쉽게 유지할 수 있습니다.

이 기적이 필요한 사람은 누구입니까?

한편으로는 이미 시장에 하이퍼컨버전스 분야에 대한 진지한 솔루션을 갖고 있는 업체들이 있으며, 이것이 바로 우리가 실제로 지향하고 있는 방향이라고 말할 수 있습니다. 이 말이 맞는 것 같지만...

반면 현장에 나가 고객과 소통해 보면 우리와 협력업체들은 전혀 그렇지 않다는 것을 알게 된다. 하이퍼컨버전스에는 많은 작업이 있습니다. 어떤 곳에서는 사람들이 그러한 솔루션이 존재하는지 몰랐고, 다른 곳에서는 비용이 많이 들고, 다른 곳에서는 대체 솔루션에 대한 테스트가 실패했으며, 다른 곳에서는 제재로 인해 구매가 전혀 금지되었습니다. 일반적으로 밭은 경작되지 않은 것으로 판명되어 처녀 토양을 재배하러갔습니다.))).

스토리지 시스템이 GCS보다 나은 경우는 언제인가요?

시장과 협력하면서 스토리지 시스템에 고전적인 방식을 사용하는 것이 언제 더 좋은지, 언제 하이퍼컨버전스를 사용하는 것이 더 나은지 묻는 질문을 자주 받습니다. GCS를 생산하는 많은 회사(특히 포트폴리오에 스토리지 시스템이 없는 회사)는 "스토리지 시스템은 더 이상 쓸모가 없으며 하이퍼컨버지드에만 해당됩니다!"라고 말합니다. 이것은 대담한 진술이지만 현실을 완전히 반영하지는 않습니다.

실제로 스토리지 시장은 실제로 하이퍼컨버전스와 유사한 솔루션을 향해 나아가고 있지만 항상 "그러나"가 있습니다.

첫째, 스토리지 시스템을 포함한 고전적 방식에 따라 구축된 데이터 센터 및 IT 인프라는 쉽게 재구축할 수 없으므로 이러한 인프라의 현대화 및 완성은 여전히 ​​5~7년 동안의 유산입니다.

둘째, 현재 구축되고 있는 인프라 대부분(즉, 러시아 연방)은 스토리지 시스템을 사용하는 고전적인 방식에 따라 구축되고 있는데, 이는 사람들이 하이퍼컨버전스를 모르기 때문이 아니라 하이퍼컨버전스 시장이 새로워서 솔루션 및 표준이 아직 확립되지 않았고, IT 담당자가 아직 교육을 받지 않았으며, 경험도 거의 없지만 지금 여기에서 데이터 센터를 구축해야 합니다. 그리고 이러한 추세는 향후 3~5년 동안 지속될 것입니다(그리고 또 다른 유산은 포인트 1 참조).

셋째, 분산 스토리지 비용인 쓰기당 2밀리초의 추가 작은 지연(물론 로컬 캐시 제외)에는 순전히 기술적 한계가 있습니다.

글쎄, 디스크 하위 시스템의 수직 확장을 좋아하는 대규모 물리적 서버의 사용을 잊지 마십시오.

스토리지 시스템이 GCS보다 더 잘 작동하는 데 필요한 인기 있는 작업이 많이 있습니다. 물론 제품 포트폴리오에 스토리지 시스템이 없는 제조업체는 우리의 의견에 동의하지 않을 것이지만 우리는 합리적으로 논쟁할 준비가 되어 있습니다. 물론 두 제품의 개발자로서 우리는 향후 간행물 중 하나에서 스토리지 시스템과 GCS를 확실히 비교할 것이며 어떤 조건에서 어느 것이 더 나은지 명확하게 보여줄 것입니다.

그리고 하이퍼컨버지드 솔루션이 스토리지 시스템보다 더 잘 작동하는 곳은 어디입니까?

위의 내용을 바탕으로 세 가지 분명한 결론을 내릴 수 있습니다.

1. 모든 제품에서 지속적으로 발생하는 기록을 위한 추가 2밀리초의 대기 시간(이제는 합성에 대해 말하는 것이 아니며 합성에 나노초가 표시될 수 있음)이 중요하지 않은 경우 하이퍼컨버전스가 적합합니다.
2. 대규모 물리적 서버의 로드가 여러 개의 작은 가상 서버로 전환되어 노드 간에 분산될 수 있는 곳에서는 하이퍼컨버전스가 잘 작동합니다.
3. 수평 확장이 수직 확장보다 우선순위가 높은 경우 GCS도 거기에서 잘 작동합니다.

이 솔루션은 무엇입니까?

1. 모든 표준 인프라 서비스(디렉터리 서비스, 메일, EDMS, 파일 서버, 중소형 ERP 및 BI 시스템 등). 우리는 이것을 '일반 컴퓨팅'이라고 부릅니다.
2. 신속하고 표준화된 수평 확장이 필요한 클라우드 제공업체의 인프라는 클라이언트를 위한 다수의 가상 머신을 쉽게 "절단"합니다.
3. 다수의 소규모 사용자 가상 머신이 균일한 클러스터 내에서 실행되고 조용히 "유동"하는 가상 데스크탑 인프라(VDI).
4. 각 지점에 내결함성을 갖춘 표준 인프라가 필요하지만 15~20개의 가상 머신으로 구성된 저렴한 인프라가 필요한 지점 네트워크.
5. 모든 분산 컴퓨팅(예: 빅 데이터 서비스). 하중이 "깊이"가 아닌 "폭"으로 가는 경우.
6. 추가적인 약간의 지연이 허용되지만 테스트이기 때문에 예산 제한이 있는 테스트 환경입니다.

현재 우리는 이러한 작업을 위해 AERODISK vAIR를 만들었고 우리가 지금까지 성공적으로 집중하고 있는 것도 바로 이 작업입니다. 아마도 이것은 곧 바뀔 것입니다. 왜냐면... 세상은 가만히 있지 않습니다.

그래서 ...

이로써 대규모 기사 시리즈의 첫 번째 부분이 완성되었습니다. 다음 기사에서는 솔루션 아키텍처와 사용된 구성 요소에 대해 설명하겠습니다.

우리는 질문, 제안 및 건설적인 분쟁을 환영합니다.

출처 : habr.com