Flexiant Cloud Orchestrator: 함께 제공되는 기능

IaaS(Virtual Data Center) 서비스를 제공하기 위해 당사는 루소닉스 우리는 상용 오케스트레이터를 사용합니다 유연한 클라우드 오케스트레이터 (FCO). 이 솔루션은 일반 대중에게 알려진 OpenStack, CloudStack과 구별되는 다소 독특한 아키텍처를 가지고 있습니다.

KVM, VmWare, Xen, Virtuozzo6/7 및 동일한 Virtuozzo의 컨테이너가 컴퓨팅 노드 하이퍼바이저로 지원됩니다. 지원되는 스토리지 옵션에는 로컬, NFS, Ceph 및 Virtuozzo Storage가 포함됩니다.

FCO는 단일 인터페이스에서 여러 클러스터의 생성 및 관리를 지원합니다. 즉, Virtuozzo 클러스터와 KVM + Ceph 클러스터를 마우스 클릭만으로 전환하여 관리할 수 있습니다.

기본적으로 FCO는 오케스트레이션 외에도 청구, 모든 설정, 결제 플러그인, 송장, 알림, 리셀러, 관세 등을 포함하는 클라우드 제공업체를 위한 포괄적인 솔루션입니다. 그러나 청구 부분은 러시아의 모든 뉘앙스를 다룰 수 없으므로 다른 솔루션을 선호하여 사용을 포기했습니다.

이미지, 디스크, 제품, 서버, 방화벽 등 모든 클라우드 리소스에 대한 권한을 배포하기 위한 유연한 시스템에 매우 만족합니다. 이 모든 것은 사용자 간에, 심지어 다른 클라이언트의 사용자 간에도 "공유"되고 권한이 부여될 수 있습니다. 각 클라이언트는 클라우드에 여러 개의 독립적인 데이터 센터를 만들고 단일 제어판에서 관리할 수 있습니다.

구조적으로 FCO는 여러 부분으로 구성되며, 각 부분에는 자체 독립적인 코드가 있고 일부에는 자체 데이터베이스가 있습니다.

지평선 – 관리 및 사용자 인터페이스
옥 – 비즈니스 로직, 빌링, 작업 관리
Tigerlily – 서비스 코디네이터는 비즈니스 로직과 클러스터 간의 정보 교환을 관리하고 조정합니다.
XVP관리자 – 클러스터 요소 관리: 노드, 스토리지, 네트워크 및 가상 머신.
XVPAgent – XVPManager와 상호 작용하기 위해 노드에 설치된 에이전트

물론 해당 주제가 관심을 불러일으킨다면 일련의 기사에 각 구성 요소의 아키텍처에 대한 자세한 이야기를 포함할 계획입니다.

FCO의 가장 큰 장점은 "박스형" 특성에 있습니다. 단순성과 미니멀리즘이 귀하의 서비스에 있습니다. 제어 노드의 경우 Ubuntu에 하나의 가상 머신이 할당되어 필요한 모든 패키지가 설치됩니다. 모든 설정은 변수 값 형식으로 구성 파일에 배치됩니다.

# cat /etc/extility/config/vars
…
export LIMIT_MAX_LIST_ADMIN_DEFAULT="30000"
export LIMIT_MAX_LIST_USER_DEFAULT="200"
export LOGDIR="/var/log/extility"
export LOG_FILE="misc.log"
export LOG_FILE_LOG4JHOSTBILLMODULE="hostbillmodule.log"
export LOG_FILE_LOG4JJADE="jade.log"
export LOG_FILE_LOG4JTL="tigerlily.log"
export LOG_FILE_LOG4JXVP="xvpmanager.log"
export LOG_FILE_VARS="misc.log"
…

전체 구성은 처음에 템플릿에서 편집된 다음 생성기가 시작됩니다.
#build-config는 vars 파일을 생성하고 서비스에 구성을 다시 읽도록 명령합니다. 사용자 인터페이스는 훌륭하고 쉽게 브랜드화할 수 있습니다.

보시다시피 인터페이스는 사용자가 제어할 수 있는 위젯으로 구성됩니다. 페이지에서 위젯을 쉽게 추가/제거하여 필요한 대시보드를 만들 수 있습니다.

폐쇄적인 특성에도 불구하고 FCO는 고도로 맞춤화 가능한 시스템입니다. 워크플로 변경을 위한 수많은 설정과 진입점이 있습니다.

1. 사용자 정의 플러그인이 지원됩니다. 예를 들어, 자체 청구 방법이나 외부 리소스를 작성하여 사용자에게 다음을 제공할 수 있습니다.
2. 특정 이벤트에 대한 사용자 정의 트리거가 지원됩니다. 예를 들어 클라이언트가 생성될 때 첫 번째 가상 머신을 클라이언트에 추가합니다.
3. 예를 들어 YouTube 비디오를 사용자 인터페이스에 직접 삽입하는 등 인터페이스의 사용자 정의 위젯이 지원됩니다.

모든 사용자 정의는 Lua를 기반으로 하는 FDL로 작성됩니다. Lua를 안다면 FDL에는 문제가 없을 것입니다.

다음은 우리가 사용하는 가장 간단한 트리거 중 하나의 예입니다. 이 트리거는 사용자가 자신의 이미지를 다른 클라이언트와 공유하는 것을 허용하지 않습니다. 이는 한 사용자가 다른 사용자를 위해 악의적인 이미지를 생성하는 것을 방지하기 위한 것입니다.

function register()
    return {"pre_user_api_publish"}
end
   
function pre_user_api_publish(p)  
    if(p==nil) then
        return{
            ref = "cancelPublishImage",
            name = "Cancel publishing",
            description = "Cancel all user’s images publishing",
            triggerType = "PRE_USER_API_CALL",
            triggerOptions = {"publishResource", "publishImage"},
            api = "TRIGGER",
            version = 1,
        }
    end

    -- Turn publishing off
    return {exitState = "CANCEL"}
   
end

레지스터 함수는 FCO 커널에 의해 호출됩니다. 호출할 함수의 이름을 반환합니다. 이 함수의 "p" 매개변수는 호출 컨텍스트를 저장하며 처음 호출될 때 비어 있습니다(nil). 그러면 트리거를 등록할 수 있습니다. TriggerType에서는 게시 작업 전에 트리거가 호출되고 사용자에게만 영향을 미친다는 것을 나타냅니다. 물론 시스템 관리자가 모든 것을 게시하는 것을 허용합니다. TriggerOptions에서는 트리거가 실행되는 작업을 자세히 설명합니다.

그리고 가장 중요한 것은 return {exitState = “CANCEL”}이며, 이것이 트리거가 개발된 이유입니다. 사용자가 제어판에서 이미지를 공유하려고 하면 실패를 반환합니다.

FCO 아키텍처에서 모든 개체(디스크, 서버, 이미지, 네트워크, 네트워크 어댑터 등)는 공통 매개변수가 있는 리소스 엔터티로 표시됩니다.

• 자원 UUID
• 리소스 이름
• 리소스 유형
• 리소스 소유자 UUID
• 리소스 상태(활성, 비활성)
• 리소스 메타데이터
• 리소스 키
• 리소스를 소유한 제품의 UUID
• 리소스 VDC

이는 모든 리소스가 동일한 원칙에 따라 작동하는 API를 사용하여 작업할 때 매우 편리합니다. 제품은 공급자가 구성하고 고객이 주문합니다. 청구서가 측면에 있으므로 고객은 패널에서 모든 제품을 자유롭게 주문할 수 있습니다. 나중에 청구 시 계산됩니다. 제품은 시간당 IP 주소, 시간당 추가 GB 또는 서버일 수 있습니다.

키를 사용하면 특정 리소스를 표시하여 작업 논리를 변경할 수 있습니다. 예를 들어 Weight 키로 세 개의 물리적 노드를 표시하고 일부 클라이언트를 동일한 키로 표시하여 이러한 노드를 해당 클라이언트에 개인적으로 할당할 수 있습니다. VM 옆에 있는 이웃을 좋아하지 않는 VIP 클라이언트를 위해 이 메커니즘을 사용합니다. 기능 자체는 훨씬 더 광범위하게 사용될 수 있습니다.

라이센싱 모델에는 물리적 노드의 각 프로세서 코어에 대한 비용 지불이 포함됩니다. 비용은 클러스터 유형의 수에도 영향을 받습니다. 예를 들어 KVM과 VMware를 함께 사용하려는 경우 라이센스 비용이 증가합니다.

FCO는 본격적인 제품이고 기능이 매우 풍부하므로 네트워크 부분의 기능에 대한 자세한 설명과 함께 여러 기사를 한 번에 준비할 계획입니다.

이 오케스트레이터와 수년 동안 작업한 결과 매우 적합하다고 평가할 수 있습니다. 아쉽게도 제품에 결함이 없는 것은 아닙니다.

• 쿼리의 데이터 양이 증가함에 따라 쿼리 속도가 느려지기 시작했기 때문에 데이터베이스를 최적화해야 했습니다.
• 한 번의 사고 후, 버그로 인해 복구 메커니즘이 작동하지 않았고, 우리는 자체 스크립트 세트를 사용하여 불행한 고객의 자동차를 복구해야 했습니다.
• 노드 비가용성을 감지하는 메커니즘은 코드에 내장되어 있으며 사용자 정의할 수 없습니다. 즉, 노드의 가용성을 결정하기 위한 자체 정책을 만들 수 없습니다.
• 로깅이 항상 상세하지는 않습니다. 때로는 특정 문제를 이해하기 위해 매우 낮은 수준으로 내려 가야 할 때 일부 구성 요소에 대한 소스 코드가 충분하지 않아 이유를 이해할 수 없습니다.

총계 : 전반적으로 제품의 인상은 좋습니다. 우리는 오케스트레이터 개발자들과 지속적으로 접촉하고 있습니다. 사람들은 건설적인 협력에 관심이 있습니다.

단순함에도 불구하고 FCO는 다양한 기능을 갖추고 있습니다. 향후 기사에서는 다음 주제에 대해 더 자세히 알아볼 계획입니다.

• FCO에서의 네트워킹
• 실시간 복구 및 FQP 프로토콜 제공
• 나만의 플러그인과 위젯 작성
• Load Balancer, Acronis 등 추가 서비스 연결
• 지원
• 노드 구성 및 구성을 위한 통합 메커니즘
• 가상 머신 메타데이터 처리

ZY 다른 측면에 관심이 있으면 의견을 작성하십시오. 계속 지켜봐 주시기 바랍니다!

출처 : habr.com