Aby świadczyć usługi IaaS (Virtual Data Center), my używamy komercyjnego orkiestratora (FKO). Rozwiązanie to posiada dość unikalną architekturę, która odróżnia je od znanych powszechnie Openstack i CloudStack.
KVM, VmWare, Xen, Virtuozzo6/7, a także kontenery z tego samego Virtuozzo są obsługiwane jako hiperwizory węzłów obliczeniowych. Obsługiwane opcje przechowywania obejmują pamięć lokalną, NFS, Ceph i Virtuozzo.
FCO wspiera tworzenie i zarządzanie wieloma klastrami z poziomu jednego interfejsu. Oznacza to, że możesz zarządzać klastrem Virtuozzo i klastrem KVM + Ceph, przełączając się między nimi jednym kliknięciem myszy.
U podstaw FCO jest kompleksowe rozwiązanie dla dostawców usług w chmurze, które oprócz orkiestracji obejmuje również rozliczenia ze wszystkimi ustawieniami, wtyczkami płatniczymi, fakturami, powiadomieniami, sprzedawcami, taryfami i tak dalej. Jednak część rozliczeniowa nie jest w stanie uwzględnić wszystkich rosyjskich niuansów, dlatego zrezygnowaliśmy z jej stosowania na rzecz innego rozwiązania.
Bardzo podoba mi się elastyczny system dystrybucji praw do wszystkich zasobów chmury: obrazów, dysków, produktów, serwerów, firewalli - wszystko to można „udostępniać” i nadawać uprawnienia pomiędzy użytkownikami, a nawet pomiędzy użytkownikami różnych klientów. Każdy klient może stworzyć w swojej chmurze kilka niezależnych centrów danych i zarządzać nimi z jednego panelu administracyjnego.
Architektonicznie FCO składa się z kilku części, z których każda ma swój własny, niezależny kod, a niektóre mają własną bazę danych.
Sylwetka na tle nieba – interfejs administratora i użytkownika
Jadeit – logika biznesowa, billing, zarządzanie zadaniami
Tygrys Lily – koordynator usług, zarządza i koordynuje wymianę informacji pomiędzy logiką biznesową a klastrami.
Menedżer XVPM – zarządzanie elementami klastra: węzłami, pamięcią masową, siecią i maszynami wirtualnymi.
XVPAgent – agent instalowany na węzłach do interakcji z XVPManager
Planujemy zamieścić szczegółowe opowiadanie o architekturze każdego komponentu w serii artykułów, jeśli oczywiście temat wzbudzi zainteresowanie.
Główna zaleta FCO wynika z jego „pudełkowego” charakteru. Prostota i minimalizm są do Twojej dyspozycji. Dla węzła sterującego przydzielana jest jedna maszyna wirtualna na Ubuntu, na której instalowane są wszystkie niezbędne pakiety. Wszystkie ustawienia umieszczane są w plikach konfiguracyjnych w postaci zmiennej-wartości:
# 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, następnie uruchamiany jest generator
#build-config, który wygeneruje plik vars i poleci usługom ponowne odczytanie konfiguracji. Interfejs użytkownika jest ładny i można go łatwo oznaczyć marką.
Jak widać interfejs składa się z widżetów, którymi użytkownik może sterować. Może łatwo dodawać/usuwać widżety ze strony, tworząc w ten sposób potrzebny mu dashboard.
Pomimo zamkniętego charakteru, FCO jest systemem o dużych możliwościach dostosowania. Ma ogromną liczbę ustawień i punktów wejścia do zmiany przepływu pracy:
- Obsługiwane są niestandardowe wtyczki, na przykład możesz napisać własną metodę rozliczeń lub własne zewnętrzne zasoby, które udostępnisz użytkownikowi
- Obsługiwane są niestandardowe wyzwalacze dla określonych zdarzeń, na przykład dodanie pierwszej maszyny wirtualnej do klienta po jej utworzeniu
- Obsługiwane są niestandardowe widżety w interfejsie, na przykład osadzanie wideo z YouTube bezpośrednio w interfejsie użytkownika.
Całe dostosowywanie jest napisane w FDL, który jest oparty na Lua. Jeśli znasz Luę, nie będzie problemów z FDL.
Oto przykład jednego z najprostszych wyzwalaczy, których używamy. Ten wyzwalacz nie pozwala użytkownikom na udostępnianie własnych obrazów innym klientom. Robimy to, aby uniemożliwić jednemu użytkownikowi utworzenie 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 rejestru zostanie wywołana przez jądro FCO. Zwróci nazwę funkcji, która ma zostać wywołana. Parametr „p” tej funkcji przechowuje kontekst wywołania i przy pierwszym wywołaniu będzie pusty (zero). Co pozwoli nam zarejestrować nasz wyzwalacz. W wyzwalaczu wskazujemy, że wyzwalacz jest wywoływany PRZED operacją publikowania i dotyczy tylko użytkowników. Oczywiście pozwalamy administratorom systemu na publikację wszystkiego. W opcji wyzwalacza szczegółowo opisujemy operacje, dla których zostanie uruchomiony wyzwalacz.
A najważniejsze jest return {exitState = „CANCEL”}, dlatego opracowano wyzwalacz. Zwróci błąd, gdy użytkownik spróbuje udostępnić swój obraz w panelu sterowania.
W architekturze FCO dowolny obiekt (dysk, serwer, obraz, sieć, karta sieciowa itp.) jest reprezentowany jako jednostka zasobu, która ma wspólne parametry:
- Identyfikator UUID zasobu
- Nazwa zasobu
- typ zasobu
- UUID właściciela zasobu
- stan zasobu (aktywny, nieaktywny)
- metadane zasobów
- klucze zasobów
- UUID produktu będącego właścicielem zasobu
- zasób VDC
Jest to bardzo wygodne podczas pracy z wykorzystaniem API, gdy wszystkie zasoby pracują na tej samej zasadzie. Produkty są konfigurowane przez dostawcę i zamawiane przez klienta. Ponieważ nasz rozliczenie jest na boku, klient może swobodnie zamówić dowolny produkt z panelu. Zostanie ona obliczona później w rozliczeniu. Produktem może być adres IP na godzinę, dodatkowy GB dysku na godzinę lub po prostu serwer.
Kluczami można oznaczać określone zasoby, aby zmienić logikę pracy z nimi. Na przykład możemy oznaczyć trzy węzły fizyczne kluczem wagi i oznaczyć niektórych klientów tym samym kluczem, tym samym przydzielając te węzły osobiście tym klientom. Używamy tego mechanizmu dla klientów VIP, którzy nie lubią sąsiadów obok swoich maszyn wirtualnych. Sama funkcjonalność może mieć znacznie szersze zastosowanie.
Model licencjonowania polega na płaceniu za każdy rdzeń procesora węzła fizycznego. Na koszt wpływa także liczba typów klastrów. Jeśli na przykład planujesz używać razem KVM i VMware, koszt licencji wzrośnie.
FCO jest produktem pełnoprawnym, jego funkcjonalność jest bardzo bogata, dlatego planujemy przygotować od razu kilka artykułów ze szczegółowym opisem funkcjonowania części sieciowej.
Pracując z tym orkiestratorem przez kilka lat, możemy go ocenić jako bardzo odpowiedni. Niestety, produkt nie jest pozbawiony wad:
- musieliśmy zoptymalizować bazę danych, ponieważ zapytania zaczęły zwalniać wraz ze wzrostem ilości zawartych w nich danych;
- po jednym wypadku mechanizm odzyskiwania nie zadziałał ze względu na błąd i musieliśmy odzyskać samochody niefortunnych klientów za pomocą własnego zestawu skryptów;
- Mechanizm wykrywania niedostępności węzła jest wbudowany w kod i nie można go dostosowywać. Oznacza to, że nie możemy tworzyć własnych zasad określających niedostępność węzła.
- rejestrowanie nie zawsze jest szczegółowe. Czasami, gdy trzeba zejść na bardzo niski poziom, aby zrozumieć konkretny problem, nie masz wystarczającej ilości kodu źródłowego dla niektórych komponentów, aby zrozumieć dlaczego;
RAZEM: Ogólnie wrażenia z produktu są dobre. Jesteśmy w stałym kontakcie z twórcami orkiestratora. Chłopaki są skłonni do konstruktywnej współpracy.
Pomimo swojej prostoty, FCO posiada szeroką funkcjonalność. W przyszłych artykułach planujemy głębiej zagłębić się w następujące tematy:
- networkingu w FCO
- zapewnianie odzyskiwania na żywo i protokołu FQP
- pisanie własnych wtyczek i widżetów
- podłączenie dodatkowych usług, takich jak Load Balancer i Acronis
- kopia zapasowa
- ujednolicony mechanizm konfiguracji i konfiguracji węzłów
- przetwarzanie metadanych maszyny wirtualnej
Z.Y. Napisz w komentarzach, jeśli interesują Cię inne aspekty. Czekać na dalsze informacje!
Źródło: www.habr.com