Flexiant Cloud Orchestrator: z czym to się je

Flexiant Cloud Orchestrator: z czym to się je

Aby świadczyć usługę IaaS (Wirtualne centrum danych), korzystamy z Rusonyx komercyjnego orkiestratora Flexiant Cloud Orchestrator (FCO). To rozwiązanie ma dość unikalną architekturę, co odróżnia je od dobrze znanego Openstack i CloudStack.

Jako hipernadzorcy węzłów obliczeniowych wspierane są KVM, VmWare, Xen, Virtuozzo6/7, a także kontenery od tego samego Virtuozzo. Wśród wspieranych pamięci - lokalna, NFS, Ceph i Virtuozzo Storage.

FCO obsługuje tworzenie wielu klastrów i zarządzanie nimi z jednego interfejsu. Oznacza to, że można zarządzać klastrem Virtuozzo i klastrem KVM + Ceph, przełączając się pomiędzy nimi jednym kliknięciem.

Zasadniczo FCO to kompleksowe rozwiązanie dla dostawców usług chmurowych, które oprócz orkiestracji zawiera również bilingi, ze wszystkimi ustawieniami, wtyczkami płatniczymi, fakturami, powiadomieniami, resellerami, taryfami i tak dalej. Niemniej jednak, część związana z billingiem nie jest w stanie pokryć wszystkich rosyjskich niuansów, dlatego zrezygnowaliśmy z jej użycia na rzecz innego rozwiązania.

Bardzo cieszy elastyczny system zarządzania prawami do wszystkich zasobów chmury: obrazy, dyski, produkty, serwery, zapory ogniowe – wszystko to można „dzielić” i przyznawać prawa między użytkownikami, a nawet między użytkownikami różnych klientów. Każdy klient może tworzyć w swojej chmurze kilka niezależnych centrów danych i zarządzać nimi z jednego panelu sterowania.

Flexiant Cloud Orchestrator: z czym to się je

Architektonicznie FCO składa się z kilku części, z których każda ma swój niezależny kod, a niektóre również swoją własną bazę danych.

Skyline – interfejs administracyjny i użytkownika
Jade – logika biznesowa, billing, zarządzanie zadaniami
Tigerlily – koordynator usługi, zarządza i koordynuje wymianą informacji pomiędzy logiką biznesową a klastrami.
XVPManager – zarządzanie elementami klastra: węzłami, pamięcią, siecią i maszynami wirtualnymi.
XVPAgent – agent instalowany na węzłach do interakcji z XVPManager

Flexiant Cloud Orchestrator: z czym to się je

Szczegółowe opisy architektury każdego komponentu planujemy ująć w cykl artykułów, jeśli, oczywiście, temat wzbudzi zainteresowanie.

Główną zaletą FCO jest jego „opakowanie”. Do dyspozycji masz prostotę i minimalizm. Dla jednostki zarządzającej przydzielona jest jedna maszyna wirtualna z Ubuntu, na której instalowane są wszystkie niezbędne pakiety. Wszystkie ustawienia są przenoszone do plików konfiguracyjnych w postaci zmienna-wartość:

# 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"
…

Cała konfiguracja jest początkowo edytowana w szablonach, a następnie uruchamiany jest generator
#build-config который сформирует файл vars и даст команду сервисам перечитать конфиг. Пользовательский интерфейс приятный и может быть легко забрендирован.

Flexiant Cloud Orchestrator: z czym to się je

Jak widać, interfejs składa się z widżetów, którymi użytkownik może zarządzać. Może łatwo dodawać/usuwać widżety ze strony, tworząc swój własny pulpit.

Pomimo swojej zamkniętości, FCO jest bardzo konfigurowalnym systemem. Posiada ogromną liczbę ustawień oraz punktów wejścia do zmiany workflow:

  1. Obsługiwane są własne wtyczki, na przykład można napisać własną metodę rozliczeniową lub własny zewnętrzny zasób do udostępniania użytkownikowi
  2. Obsługiwane są własne wyzwalacze na określone zdarzenia, na przykład dodanie pierwszej maszyny wirtualnej klientowi przy jego tworzeniu
  3. Obsługiwane są własne widżety w interfejsie, na przykład wbudowanie wideo z YouTube bezpośrednio w interfejsie użytkownika.

Cała personalizacja jest pisana w języku FDL, który opiera się na Lua. Jeśli znasz Lua, z FDL nie będziesz miał żadnych problemów.

Oto przykład jednego z najprostszych wyzwalaczy, które stosujemy. Ten wyzwalacz nie pozwala użytkownikom dzielić się własnymi obrazami z innymi klientami. Robimy to, aby jeden użytkownik nie mógł stworzyć złośliwego obrazu dla innych użytkowników.

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

Funkcja register zostanie wywołana przez rdzeń FCO. Zwróci nazwę funkcji, którą trzeba będzie wywołać. Parametr „p” tej funkcji przechowuje kontekst wywołania, a przy pierwszym wywołaniu będzie pusty (nil). Umożliwi nam to zarejestrowanie naszego wyzwalacza. W triggerType pokazujemy, że wyzwalacz jest wywoływany PRZED operacją publikacji i rozciąga się tylko na użytkowników. Administratorom systemu, rzecz jasna, pozwalamy publikować wszystko. W triggerOptions szczegółowo opisujemy operacje, dla których wyzwalacz będzie działał.

I najważniejsze – return {exitState = “CANCEL”}, do czego wyzwalacz został zaprojektowany. Zwróci niepowodzenie, gdy użytkownik spróbuje podzielić się swoim obrazem w panelu zarządzania.

W architekturze FCO – każdy obiekt (dysk, serwer, obraz, sieć, adapter sieciowy itp.) reprezentowany jest jako encja Resource, która ma wspólne parametry:

  • UUID zasobu
  • nazwa zasobu
  • typ zasobu
  • UUID właściciela zasobu
  • status zasobu (aktywny, nieaktywny)
  • metadane zasobu
  • klucze zasobu
  • UUID produktu, do którego należy zasób
  • VDC zasobu

Jest to bardzo wygodne w pracy z API, gdyż ze wszystkimi zasobami pracuje się na tej samej zasadzie. Produkty są konfigurowane przez dostawcę, a zamawia je klient. Ponieważ nasze rozliczenia znajdują się z boku, klient może swobodnie i bezpłatnie zamawiać dowolny produkt z panelu. Zostanie on doliczony później w rozliczeniach. Produktem może być – adres IP na godzinę, dodatkowy GB dysku na godzinę lub po prostu serwer.

Klucze można użyć do oznaczenia określonych zasobów w celu zmiany logiki pracy z nimi. Na przykład możemy oznaczyć trzy fizyczne węzły kluczem Weight i oznaczyć niektórych klientów tym samym kluczem, wyróżniając w ten sposób te węzły dla danych klientów. Taki mechanizm stosujemy dla klientów VIP, którzy nie lubią sąsiadów obok swoich VM. Sam funkcjonalność można zastosować dużo szerzej.

Model licencjonowania zakłada opłatę za każde rdzeń procesora fizycznego węzła. Na koszt wpływa również liczba typów klastrów. Jeśli planowane jest użycie razem, na przykład, KVM i VMware, to koszt licencji wzrośnie.

FCO jest pełnoprawnym produktem, jego funkcjonalność jest bardzo bogata, dlatego planujemy przygotować od razu kilka artykułów z szczegółowym opisem działania części sieciowej.

Pracując z tym orkiestratorem przez kilka lat, możemy go ocenić jako bardzo dobry. Niestety, produkt nie jest wolny od wad:

  • musieliśmy optymalizować bazę danych, ponieważ zapytania zaczęły zwalniać przy wzroście ilości danych w nich;
  • po jednej awarii z powodu błędu nie zadziałał mechanizm odzyskiwania, i musieliśmy uruchomić maszyny nieszczęsnych klientów naszym zestawem skryptów;
  • mechanizm wykrywania niedostępności węzła jest zaszyty w kodzie i nie podlega dostosowaniu. To znaczy, że nie możemy tworzyć własnych polityk wykrywania niedostępności węzła.
  • Logowanie nie zawsze jest szczegółowe. Czasami, gdy trzeba zejść na bardzo niski poziom, aby rozwiązać określony problem, brakuje kodu źródłowego niektórych komponentów, aby zrozumieć przyczyny;

RAZEM: Ogólnie rzecz biorąc, wrażenia z produktu są dobre. Jesteśmy w stałym kontakcie z deweloperami orchestratora. Chłopaki są otwarci na konstruktywną współpracę.

Pomimo swojej prostoty, FCO posiada szeroką funkcjonalność. W przyszłych artykułach planujemy zagłębić się w następujące tematy:

  • organizacja sieci w FCO
  • zapewnienie live-recovery i protokołu FQP
  • pisanie własnych wtyczek i widgetów
  • podłączenie dodatkowych usług, takich jak Load Balancer i Acronis
  • backup
  • zunifikowany mechanizm konfiguracji i ustawienia węzłów
  • przetwarzanie metadanych maszyn wirtualnych

P.S. Piszcie w komentarzach, jeśli interesują Was inne aspekty. Bądźcie na bieżąco!

Źródło: habr.com

Kup solidny hosting stron z ochroną przed DDoS, serwery VPS VDS 🔥 Kup solidny hosting stron z ochroną przed DDoS, serwery VPS VDS | ProHoster