Hystax Cloud Migration: 구름을 타고

재해 복구 솔루션 시장의 젊은 기업 중 하나는 2016년에 설립된 러시아 스타트업인 Hystax입니다. 재해 복구라는 주제가 매우 인기 있고 시장 경쟁이 극도로 치열하기 때문에 스타트업은 서로 다른 클라우드 인프라 간의 마이그레이션에 집중하기로 결정했습니다. 클라우드로의 간단하고 빠른 마이그레이션을 구성할 수 있는 제품은 Onlanta의 클라이언트인 사용자에게도 매우 유용할 것입니다. 온클라우드.ru. 그렇게 저는 Hystax를 알게 되었고, 그 기능을 테스트하기 시작했습니다. 이 기사에서 그 결과를 알려 드리겠습니다.

Hystax의 주요 특징은 다양한 가상화 플랫폼, 게스트 운영 체제 및 클라우드 서비스를 지원하는 폭넓은 기능을 갖추고 있어 언제 어디서나 워크로드를 전송할 수 있다는 것입니다.

이를 통해 서비스의 내결함성을 높이는 DR 솔루션을 만들 수 있을 뿐만 아니라 서로 다른 사이트와 하이퍼스케일러 간에 리소스를 빠르고 유연하게 마이그레이션하여 비용 절감을 높이고 특정 순간에 특정 서비스에 가장 적합한 솔루션을 선택할 수 있습니다. 제목 사진에 나열된 플랫폼 외에도 회사는 Yandex.Cloud, CROC Cloud Services, Mail.ru 등 러시아 클라우드 제공업체와도 적극적으로 협력하고 있습니다. 2020년에 회사가 Skolkovo에 R&D 센터를 개설했다는 점도 주목할 가치가 있습니다. 

시장에 나와 있는 많은 플레이어가 하나의 솔루션을 선택한다는 것은 좋은 가격 정책과 제품의 높은 적용 가능성을 의미하며, 우리는 이를 실제로 테스트하기로 결정했습니다.

따라서 우리의 테스트 작업은 VMware 테스트 사이트와 물리적 시스템을 VMware에서 관리하는 공급자 사이트로 마이그레이션하는 것으로 구성됩니다. 예, 이러한 마이그레이션을 수행할 수 있는 솔루션은 많이 있지만 우리는 Hystax를 범용 도구로 간주하며 가능한 모든 조합에서 마이그레이션을 테스트하는 것은 단순히 비현실적인 작업입니다. 그리고 Oncloud.ru 클라우드는 VMware를 기반으로 특별히 구축되었으므로 이 플랫폼은 우리의 관심 대상입니다. 다음으로 일반적으로 플랫폼과 독립적이며 VMware는 어떤 측면에서든 다른 공급업체의 플랫폼으로 대체될 수 있다는 기본 작동 원리에 대해 설명하겠습니다. 

첫 번째 단계는 시스템의 제어판인 Hystax Acura를 배포하는 것입니다.

템플릿에서 펼쳐집니다. 어떤 이유에서인지 우리의 경우에는 완전히 정확하지 않았으며 권장되는 8CPU 대신 리소스의 절반으로 16Gb가 배포되었습니다. 따라서 이를 변경하는 것을 기억해야 합니다. 그렇지 않으면 모든 것이 구축된 VM 내부의 컨테이너 인프라가 시작되지 않고 포털에 액세스할 수 없게 됩니다. 안에 배포 요구 사항 필요한 리소스와 모든 시스템 구성 요소에 대한 포트가 자세히 설명되어 있습니다. 

템플릿을 통해 IP 주소를 설정하는 데 어려움도 있어서 콘솔에서 변경했습니다. 그런 다음 관리 웹 인터페이스로 이동하여 초기 구성 마법사를 완료할 수 있습니다. 

끝점 – vCenter의 IP 또는 FQDN입니다. 
로그인 및 비밀번호 – 이것은 분명합니다. 
대상 ESXi 호스트 이름은 복제가 수행될 클러스터의 호스트 중 하나입니다. 
대상 데이터스토어는 복제가 수행될 클러스터의 데이터스토어 중 하나입니다.
Hystax Acura 제어판 공용 IP – 제어판을 사용할 수 있는 주소입니다.

호스트와 데이터스토어에 관해 약간의 설명이 필요합니다. 사실 Hystax 복제는 호스트 및 데이터 저장소 수준에서 작동합니다. 다음으로 테넌트의 호스트와 데이터스토어를 변경하는 방법을 알려드리겠습니다. 하지만 문제는 다릅니다. Hystax는 리소스 풀 작업을 지원하지 않습니다. 복제본은 항상 클러스터의 루트로 이동합니다(이 자료를 작성할 당시 Hystax 직원이 업데이트된 버전을 출시하여 리소스 풀 지원에 관한 기능 요청을 신속하게 구현했습니다). vCloud Director도 지원되지 않습니다. 내 경우처럼 테넌트가 전체 클러스터에 대한 관리자 권한을 갖고 있지 않고 특정 리소스 풀에 대해서만 관리 권한을 갖고 있으며 우리가 Hystax에 대한 액세스 권한을 부여한 경우 테넌트는 이러한 VM을 독립적으로 복제하고 시작할 수 있지만 VMware 인프라에서는 이를 볼 수 없으며 이에 따라 가상 머신을 추가로 관리합니다. 클러스터 관리자는 VM을 원하는 리소스 풀로 이동하거나 이를 vCloud Director로 가져와야 합니다.

나는 왜 이런 점들에 그렇게 집중하고 있는가? 왜냐하면 제가 제품의 개념을 이해하는 한 고객은 Acura 패널을 사용하여 어떤 마이그레이션이나 DR을 독립적으로 구현할 수 있어야 하기 때문입니다. 그러나 지금까지 VMware 지원은 유사한 메커니즘이 이미 구현된 OpenStack 지원 수준보다 약간 뒤떨어져 있습니다. 

하지만 배포로 돌아가 보겠습니다. 우선, 패널 초기 설정 후 시스템에 첫 번째 테넌트를 생성해야 합니다.

여기서는 모든 필드가 명확하며 Cloud 필드에 대해서만 말씀 드리겠습니다. 초기 구성 중에 생성한 "기본" 클라우드가 이미 있습니다. 그러나 각 테넌트를 자체 데이터 저장소와 자체 리소스 풀에 배치하려면 각 고객을 위한 별도의 클라우드를 생성하여 이를 구현할 수 있습니다.

새 클라우드를 추가하는 양식에서 초기 구성과 동일한 매개변수를 지정하고(동일한 호스트도 사용할 수 있음) 특정 고객에게 필요한 데이터 저장소를 표시하며 이제 추가 매개변수에서 필요한 리소스를 개별적으로 지정할 수 있습니다. 풀 {"resource_pool": "YOUR_POOL_NAME"} 

아시다시피 테넌트 생성 양식에는 리소스 할당이나 할당량에 대한 내용이 없습니다. 시스템에는 이러한 내용이 없습니다. 동시 복제본 수, 복제할 머신 수 또는 기타 매개변수로 테넌트를 제한하는 것은 불가능합니다. 그래서 우리는 첫 번째 테넌트를 만들었습니다. 이제 완전히 논리적이지는 않지만 필수 사항인 클라우드 에이전트 설치가 있습니다. 특정 고객의 페이지에 에이전트를 다운로드하기 때문에 비논리적입니다.

동시에 생성된 테넌트에 연결되지 않으며 모든 고객이 이를 통해 작업합니다(또는 배포하는 경우 여러 개를 통해). 한 에이전트는 10개의 동시 세션을 지원합니다. 하나의 머신은 하나의 세션으로 계산됩니다. 디스크 수는 중요하지 않습니다. 현재까지 VMware에서는 Acura 자체에 에이전트를 확장하는 메커니즘이 없습니다. 불쾌한 순간이 한 가지 더 있습니다. 더 많은 배포가 필요한지 또는 현재 설치가 충분한지 결론을 내리기 위해 Acura 패널에서 이 에이전트의 "처분"을 볼 기회가 없습니다. 결과적으로 스탠드는 다음과 같습니다.

고객 포털에 액세스하는 다음 단계는 계정을 생성하는 것입니다(먼저 이 사용자에게 적용될 역할을 생성합니다).

이제 고객은 포털을 독립적으로 사용할 수 있습니다. 그가 해야 할 일은 포털에서 에이전트를 다운로드하여 그의 편에 설치하는 것뿐입니다. 에이전트에는 Linux, Windows, VMware의 세 가지 유형이 있습니다.

처음 두 개는 물리적 또는 VMware 이외의 하이퍼바이저에 있는 가상 머신에 설치됩니다. 추가로 구성할 필요가 없으며 에이전트가 다운로드되어 이미 노크할 위치를 알고 있으며 문자 그대로 XNUMX분 안에 자동차가 Acura 패널에 표시됩니다. VMware 에이전트를 사용하면 상황이 좀 더 복잡해집니다. 문제는 이미 준비되어 있고 필요한 구성이 포함된 포털에서도 VMware용 에이전트가 다운로드된다는 것입니다. 그러나 VMware 에이전트는 Acura 포털에 대해 아는 것 외에도 배포될 가상화 시스템에 대해서도 알아야 합니다.

실제로 시스템은 VMware 에이전트를 처음 다운로드할 때 이 데이터를 제공하도록 요청합니다. 문제는 보안에 대한 보편적 사랑의 시대에 모든 사람이 다른 사람의 포털에 관리자 비밀번호를 표시하고 싶어하지 않는다는 것입니다. 이는 충분히 이해할 수 있습니다. 배포 후에는 내부에서 어떤 방식으로든 에이전트를 구성할 수 없습니다(네트워크 설정만 변경할 수 있음). 여기서 나는 특히 조심스러운 고객에게 어려움을 겪을 것으로 예상합니다. 

따라서 에이전트를 설치한 후 Acura 패널로 돌아가서 모든 자동차를 볼 수 있습니다.

며칠 동안 시스템 작업을 해왔기 때문에 여러 주에 자동차가 있습니다. 기본 그룹에 모두 포함되어 있지만 필요에 따라 별도의 그룹을 만들고 해당 그룹에 자동차를 전송할 수 있습니다. 이는 아무 영향도 미치지 않습니다. 보다 편리한 작업을 위해 데이터를 논리적으로 표현하고 그룹화하는 것뿐입니다. 이 후에 가장 먼저 해야 할 가장 중요한 일은 마이그레이션 프로세스를 시작하는 것입니다. 이 작업은 수동으로 수행하거나 모든 시스템에 대한 대량 작업을 한 번에 포함하여 일정을 설정하여 수행할 수 있습니다.

Hystax가 마이그레이션을 위한 제품으로 포지셔닝되었음을 상기시켜 드리겠습니다. 따라서 복제된 머신을 실행하려면 DR 계획을 수립해야 한다는 것은 놀라운 일이 아닙니다. 이미 동기화된 상태인 머신에 대한 계획을 세울 수 있습니다. 하나의 특정 VM과 모든 머신에 대해 동시에 생성할 수 있습니다.

DR 계획을 생성할 때 매개변수 세트는 마이그레이션할 인프라에 따라 다릅니다. VMware 환경에서는 최소한의 매개변수 세트를 사용할 수 있습니다. 머신에 대한 Re-IP도 지원되지 않습니다. 이와 관련하여 우리는 다음 사항에 관심이 있습니다. VM 설명에서 "서브넷" 매개 변수: "VMNetwork", 여기서 VM을 클러스터의 특정 네트워크에 바인딩합니다. 순위 – 여러 VM을 마이그레이션할 때 관련되며 시작 순서를 결정합니다. 특징 – VM 구성(이 경우 1CPU, 2GB RAM)을 설명합니다. 서브넷 섹션에서 "서브넷"을 정의합니다. "VMNetwork"는 VMware "VM 네트워크"와 연결됩니다. 

DR 계획을 생성할 때 여러 데이터 저장소에 디스크를 "분산"할 수 있는 방법은 없습니다. 이는 이 클라이언트 클라우드에 대해 정의된 동일한 데이터 저장소에 위치하며, 다른 클래스의 디스크가 있는 경우 머신을 시작할 때 약간의 어려움이 발생할 수 있습니다. Hystax에서 VM을 시작하고 "분리"한 후에도 필요한 데이터 저장소로의 별도 마이그레이션 디스크가 필요합니다. 그런 다음 우리가 해야 할 일은 DR 계획을 시작하고 자동차가 상승할 때까지 기다리는 것뿐입니다. P2V/V2V 변환 과정에도 시간이 걸립니다. 내 가장 큰 테스트 시스템인 100GB(디스크 10개 포함)에서는 최대 XNUMX분이 걸렸습니다.

그런 다음 실행 중인 VM, VM의 서비스, 데이터 일관성을 확인하고 기타 검사를 수행해야 합니다. 

그런 다음 두 가지 방법이 있습니다. 

1. 삭제 – 실행 중인 DR 계획을 삭제합니다. 이 작업을 수행하면 실행 중인 VM이 종료됩니다. 이 복제본은 아무데도 가지 않습니다. 
2. 분리 – 복제된 자동차를 Acura에서 떼어냅니다. 즉, 실제로 마이그레이션 프로세스를 완료합니다. 

솔루션의 장점: 

• 클라이언트와 공급자 모두의 설치 및 구성 용이성 
• 마이그레이션 설정, DR 계획 생성 및 복제본 실행 용이성
• 지원 및 개발자는 발견된 문제에 매우 신속하게 대응하고 플랫폼 또는 에이전트 업데이트를 사용하여 문제를 해결합니다. 

죄수 팀은 

• Vmware 지원이 부족합니다.
• 플랫폼의 테넌트에 대한 할당량이 없습니다. 

또한 공급업체에 제출한 기능 요청도 작성했습니다.

1. 클라우드 에이전트를 위한 Acura 관리 콘솔의 사용량 모니터링 및 배포
2. 세입자에 대한 할당량 가용성; 
3. 각 테넌트의 동시 복제 수 및 속도를 제한하는 기능 
4. VMware vCloud Director 지원; 
5. 리소스 풀 지원(테스트 중에 구현됨)
6. Acura 패널에 클라이언트 인프라의 자격 증명을 입력하지 않고 에이전트 자체에서 VMware 에이전트를 구성하는 기능
7.  DR 계획을 실행할 때 VM 시작 프로세스의 "시각화". 

나에게 큰 비판을 불러일으킨 유일한 것은 문서였습니다. 나는 "블랙박스"를 별로 좋아하지 않으며 제품이 내부에서 어떻게 작동하는지에 대한 자세한 문서가 있는 것을 선호합니다. 그리고 AWS 및 OpenStack에 대해 제품이 어느 정도 설명되어 있다면 VMware의 경우 문서가 거의 없습니다. 

Acura 패널 배포에 대해서만 설명하는 설치 가이드가 있고, Cloud 에이전트도 필요하다는 내용은 한마디도 없습니다. 좋은 제품 사양의 전체 세트가 있습니다. AWS와 OpenStack을 예로 들어 "처음부터 끝까지" 설정을 설명하는 문서가 있으며(나에게는 블로그 게시물처럼 보이지만) 아주 작은 지식 베이스도 있습니다. 

일반적으로 이것은 대규모 공급업체에서 익숙한 문서 형식이 아니기 때문에 완전히 편안하지 않았습니다. 동시에, 나는 이 문서에서 시스템이 "내부"에서 어떻게 작동하는지에 대한 몇 가지 미묘한 차이에 대한 답을 찾지 못했습니다. 기술 지원을 통해 많은 질문을 명확히 해야 했고 이로 인해 스탠드를 배치하고 수행하는 프로세스가 상당히 지연되었습니다. 테스트. 

요약하자면, 전반적으로 제품과 회사의 작업 접근 방식이 마음에 들었다고 말할 수 있습니다. 예, 단점이 있습니다. (VMware와 관련하여) 기능이 매우 부족합니다. 우선 회사는 여전히 퍼블릭 클라우드, 특히 AWS에 초점을 맞추고 있으며 일부에게는 이것으로 충분할 것이 분명합니다. 오늘날 많은 기업이 멀티 클라우드 전략을 선택할 때 이렇게 간단하고 편리한 제품을 갖는 것은 매우 중요합니다. 경쟁사에 비해 훨씬 저렴한 가격을 고려하면 이 제품은 매우 매력적입니다.

우리는 팀원을 찾고 있습니다 리드 모니터링 시스템 엔지니어. 어쩌면 당신일까요?

출처 : habr.com