Kubernetes i Borg: narzędzia open source do zarządzania centrami danych

0

Borg, Kubernetes i wiele, wiele innych rozwiązań Google – oraz ich poszczególnych funkcji – rozwijanych jest m.in. przez inżynierów w Warszawie. Tutejszy dział R&D zatrudnia już ponad 100 osób. W tym roku chce zatrudnić kilkadziesiąt kolejnych. Szybki wzrost związany jest z projektami realizowanymi wokół Google Cloud Platform.

Polski dział R&D wyspecjalizował się w budowie narzędzi do automatycznego dostosowywania zasobów IT do potrzeb ich użytkowników. To całkowicie polska domena w Google. Kierowany przez Jarka Kuśmierka zespół inżynierów w warszawskim biurze pracował również nad odpowiednimi modułami systemu Borg służącemu do zarządzania centrami danych Google na potrzeby kilkudziesięciu tysięcy deweloperów tej firmy, ale i systemu Kubernetes, z którego korzystają klienci Google Cloud Platform. Platforma ta służy firmom IT i programistom do tego, aby mogli oni uruchamiać kod własnych aplikacji w chmurze. W przypadku tej ostatniej platformy, polscy inżynierowie stworzyli także jej front-end, m.in. Developers Console.

Narzędzie Google rozwijane nad Wisłą
Warszawskie biuro Google ma już 10 lat. Ale zespół inżynierów działa w nim dopiero od września 2011 roku. Rok temu do Warszawy – i innych miast europejskich, w tym Zurichu –  przeniesiono pracowników krakowskiego działu badawczo-rozwojowego firmy. Początkowo warszawski dział R&D rozwijał się powoli. Zmieniło się to gdy polscy inżynierowie zaczęli pracować nad platformami cloud computing. Dziś wśród 100 inżynierów – w tym ok. 20% to kobiety – pracują nie tylko programiści, ale także UX Designerzy oraz Project i Program Managerowie. Warszawski dział badawczo-rozwojowy w tym roku chce zatrudnić kilkadziesiąt kolejnych osób, w tym osoby z doświadczeniem przy realizacji projektów.

„Znajomość technologii – choć istotna – jest mniej ważna niż umiejętność kreatywnego myślenia i podchodzenia do rozwiązywania problemów, zadawania pytań „a po co to robimy?. Kandydaci muszą oczywiście znać jakiś język programowania i na jego podstawie przeprowadzana jest rozmowa z kandydatem. Stawiamy jednak na proces myślowy, a nie wiedzę. Tym bardziej, że i tak wybranych kandydatów będziemy szkolić z narzędzi, które opracowujemy wewnętrznie” – mówi Jarek Kuśmierek. „Teraz oprócz programistów poszukujemy także Product Managerów, architektów, osoby zarządzające zespołami programistów” – dodaje.

W Krakowie polscy inżynierowie pracowali nad wieloma projektami z różnych działów Google. W Warszawie odpowiadają za rozwój jednej, dużej funkcjonalności automatycznego rozpraszania obciążenia infrastruktury IT, która jest elementem takich systemów zarządzania centrami danych, jak Borg i Kubernetes. Obecny zespół ma więc większą samodzielność.

Dostęp do danych i zapytania SQL w wersji Google
„Początkowo rozwijaliśmy tylko rozwiązania dla centrów danych Google, ułatwiających developerom ‘odpalanie’ kodu ich aplikacji. Odkąd uruchomiono Google Cloud Platform, rozwijamy też narzędzia dla użytkowników zewnętrznych. Pracując nad projektami dla nich musimy jednak kłaść większy nacisk na projektowanie interfejsu użytkownika. Stąd duża u nas grupa badaczy i projektantów interfejsów użytkownika” – mówi Jarek Kuśmierek.

Jednym z rozwiązań, nad którymi inżynierowie w Warszawie pracują wraz ze swoimi amerykańskimi kolegami jest DataFlow – stworzona dla klientów zewnętrznych wersja mechanizmu MapReduce. Ułatwia on dostęp do danych przechowywanych w Google File System. Ten zaś wykorzystuje koncepcję przetwarzania i przechowywania danych w systemie rozproszonym Collossus. Google stworzył także własny silnik wykonywania zapytań SQL – Dremel. Jego odpowiednikiem dla klientów zewnętrznych jest rozwiązanie o nazwie BigQuery. „Dzięki niemu można ‘wrzucić’ zgromadzone dane i uruchomić ich analizę w naszej chmurze. Użytkownicy płacą jedynie za czas wykorzystania maszyn niezbędnych do analizy danych, nawet jeśli jest to 1000 maszyn wirtualnych, które pracowały przez zaledwie 5 minut. Choć oczywiście użytkownicy Google Cloud Platform mogą skorzystać też z silnika MySQL, czy innego, komercyjnego rozwiązania” – opowiada Jarek Kuśmierek.

Polscy inżynierowie odpowiadają także za zarządzanie maszynami wirtualnymi w ramach Google Cloud Platform, w tym za automatyzację analizy informacji na temat tego, ile ich de facto potrzeba.

Borg: narzędzie maksymalnie ułatwiające pracę programistów Google
Jak wspomina Jarek Kuśmierek, na początku każdy z zespołów deweloperów – związanych z wyszukiwarką, YouTube i innymi usługami Google – martwił się o swoje zasoby. Potem inżynierowie Google zaczęli pracować nad narzędziami, które miały maksymalnie ułatwić pracę programistom, w tym automatycznie uruchamiać poszczególne procesy. „Pierwszym rozwiązaniem był Borg” – mówi szef warszawskiego zespołu inżynierów Google. „Celem jego stworzenia było zbudowanie abstrakcji jednej wielkiej maszyny, która się nigdy nie psuje i ma nieograniczone zasoby. Borg zarządza dziś wszystkim centrami danych Google” – dodaje.

Borg zarządza pulą maszyn, a także tym, jakie systemy na nich pracują, ile zasobów potrzebują, a także metodologią najbardziej efektywnego upakowania maszyn. Jak wspominają przedstawiciele Google, jeśli mamy mniej ważne i bardziej ważne zadania na tej samej maszynie, to możemy zarządzać nimi w sposób bardzo dynamiczny, zabierając i oddając ten sam zestaw zasobów z korzyścią dla systemu, który w danej chwili „bardziej” go potrzebuje. Borg zarządza też cyklem życia maszyn fizycznych. Informuje, gdy trzeba je naprawić. Wówczas znajdujące się na niej procesy automatycznie przenosi na inny serwer.

System ten automatycznie analizuje – bazując na analizie kodu i danych historycznych – jak dużo zasobów potrzebuje dany program. Bardziej zaawansowani użytkownicy sami określą, że ma to być np. 5 maszyn wirtualnych, każda z 10 GB pamięci RAM. Mniej zaawansowany może jednak nie posiadać informacji o potrzebnych zasobach. Wówczas Borg automatycznie dostosowuje je do potrzeb jego aplikacji. Przykładowo porównuje ją z innymi serwisami, liczbą maszyn wirtualnych, na których pracują lub pracowały. W trakcie działania tego programu samodzielnie także dostosowuje wykorzystanie infrastruktury IT – dodaje lub odbiera zasoby w przypadku, gdy są zbyt duże. „Podstawową jednostką w Borg jest centrum danych. Zaawansowany użytkownik wie gdzie uruchomić swój program. Ten mniej zaawansowany pozostawia to naszemu systemowi. Na decyzje podejmowane przez Borga wpływają m.in. fakt, skąd dane są czytane najczęściej, kto z nich korzysta, a nawet to w którym z naszych centrów danych planowane są naprawy serwisowe” – opowiada Jarek Kuśmierek.

Zarządzanie klastrami kontenerów i maszyn wirtualnych
Deweloperzy w Google korzystają do uruchamiania swoich programów i usług z kontenerów. W kontenerach mechanizm izolacji istnieje na poziomie systemu operacyjnego, który znajduje się na hoście. „Tak naprawdę tę funkcjonalność zbudowaliśmy my i dorzuciliśmy ją do jądra Linuxa. Na tej podstawie powstał Docker.” – mówi Jarek Kuśmierek. Wszystkie kontenery w Google – a co tydzień powstaje ich ponad 2 miliardy –  korzystają z tej samej dystrybucji systemu Linux, który znajduje się po stronie hosta. W kontenerze nie ma też zapisanych plików. Dzięki temu taka maszyna „wstaje” znacznie szybciej niż w kilkadziesiąt sekund, jak w przypadku maszyn wirtualnych. Te oferowane są w ramach Google Cloud Platform, ale tylko dlatego, że jej użytkownicy chcą mieć swobodę m.in. w wyborze systemu operacyjnego, skorzystać z innej dystrybucji Linuxa, czy systemu Windows. Później – wewnątrz maszyny wirtualnej – użytkownicy mogą zarządzać swoim oprogramowaniem bezpośrednio lub pakując je w kontenery, jeśli chcą uruchomić więcej niż jeden program w maszynie wirtualnej.

Do zarządzania zestawem kontenerów uruchomionych w klastrze maszyn wirtualnych wykorzystywany jest system Kubernetes. Jest to odpowiednik open source systemu Borg, który został udostępnionym klientom zewnętrznym. „Borg jest bardzo mocno wpięty w nasze systemy wewnętrzne. Wykorzystaliśmy więc ideę za nim stojącą, ale jego implementację przeprowadziliśmy od początku. Są różnice między każdym z tych systemów. Kubernetes ma nieco mniejsze możliwości niż Borg” – wyjaśnia Jarek Kuśmierek.

Kubernetes rozwijany jest m.in. przez inżynierów Google w Polsce. Zarządza klastrem maszyn, na których można uruchamiać kontenery. Rozwiązanie to samodzielnie przydziela niezbędne zasoby. Użytkownik nie musi martwić się, na jakiej maszynie i ile kontenerów zostanie uruchomionych. Nawet jeśli system ma budowę wielowarstwową, jest oparty na mikroserwisach, to Kubernetes automatycznie zmapuje jego strukturę, a następnie wyskaluje niezbędne zasoby. Kubernetes korzysta z kontenerów Dockera, choć Google wykorzystuje własne, wewnętrznie opracowane kontenery.

Google we własnych centrach danych korzysta z wielu, dedykowanych rozwiązań. Dotyczy to m.in. systemu chłodzenia, czy produkowanych na zamówienie serwerów korzystających np. z innego napięcia, niż standardowe 230 V, np. 12 V i 48 V. Przy tej skali działania – na całym świecie jest kilkanaście centrów danych Google, a w każdym pracują dziesiątki tysięcy maszyn – można tworzyć własne rozwiązania infrastrukturalne.

Infrastruktura IT ma być przezroczysta dla użytkownika
Dzięki rozwijanym przez Google – m.in. w Polsce – narzędziom, użytkownicy Google Cloud Platform nie muszą martwić się w jakiej lokalizacji, na ilu maszynach i w ilu kopiach zostanie uruchomiony ich program. Wystarczy, że napiszą kod, skompilują jego wersję binarną i podadzą ścieżkę do repozytorium, w którym się ona znajduje. Za całą resztę odpowiadają rozwiązania dostępne na Google Cloud Platform. Na Google Cloud Platform można – choć nie trzeba – wykorzystywać Kubernetesa. Z możliwości tego systemu korzysta się się głównie, jeśli użytkownik chce uruchomić więcej niż jedno zadanie na maszynie i niezależnie nimi zarządzać. Jeśli ma jeden system na maszynę – lub więcej, ale ręcznie zarządza nimi – to może używać samych maszyn wirtualnych. W Warszawie budowana jest wspomniana automatyka dla wielu rozwiązań w ramach Google Cloud Platform, jak i dla Kubernetesa.

W centrach danych zautomatyzowano zarządzanie obciążeniami, przydzielaniem zasobów, a nawet – w zależności od pory dnia – „przerzucaniem” kopii programu pomiędzy centrami danych w różnych regionach świata. Wewnętrznie wbudowane te narzędzia ma Borg. Na Google Cloud Platform wykorzystywane są w funkcji Autoscalingu. Gdy w Europie jest dzień to więcej jego instancji znajdzie się w tutejszych centrach danych, gdy budzą się stany część z nich jest „zabijana”, a uruchamiane są dodatkowe kopie systemu w centrach danych w USA. Wszystko zależy od tego, gdzie aktualnie są użytkownicy danej usługi, czy serwisu. Dzieje się zaś tak ze względu optymalizację opóźnień w komunikacji między użytkownikiem końcowym a serwerem Google.

Oczywiście w ramach Google Cloud Platform można zadecydować, w którym miejscu będą przechowywane dane. Zwłaszcza w kontekście regulacji w Polsce i Unii Europejskiej. Mogą to być wyłącznie centra danych znajdujące się w obrębie UE. Choć ograniczenie to – ze względu na sposób funkcjonowania narzędzi takich, jak Kubernetes – dotyczyć może jedynie określonego regionu, a nie konkretnego centrum danych w wybranym kraju.

Zestaw narzędzi dla programistów w chmurze Google
Programiści uruchamiający kod w Google Cloud Platform mogą korzystać z takich narzędzi, jak AppEngine i CloudFunctions. Pierwsze uruchamia napisany przez programistę kod po jego wgraniu, drugie dopiero w momencie gdy nastąpi określone zdarzenie. Wówczas automatycznie wywoływana jest konkretna usługa, np. przeskanuj, skopiuj, przenieś do konkretnego katalogu czy też poinformuj mnie, gdy coś się zmieni w moim katalogu na GitHub. Po wykonaniu danej funkcji zasoby są automatycznie zwalniane, a użytkownik płaci tylko za czas faktycznego z niej korzystania. W tle system analizuje jak długo ma to być. Maszyna wirtualna kasowana jest po każdym użyciu, a w miarę potrzeb uruchamiana jest kolejna. Dzieje się tak nawet jeśli użytkownik chce uruchomić ponownie ten sam proces. Powodem jest zapewnienie bezpieczeństwa i niezawodności. Jeśli nasz kod ma jakiś błąd, który ujawnia się w rzadkich przypadkach – i “śmieci” w lokalnym środowisku – to wpływa tylko na aktualne uruchomienie danego system, a nie na wszystkie kolejne jego uruchomienia w przyszłości.

Na Google Cloud Platform znajduje się wiele więcej narzędzi automatyzujących pewne procesy. Podstawowym jest Managed Instance Group, które tworzy – odpowiednią do potrzeb użytkownika – ilość maszyn wirtualnych. AutoScaler dostosowuje automatycznie ich ilość do aktualnego obciążenia. Liczone jest ono nie w oparciu o obciążenie CPU procesora, ale o liczbę requestów szacowanym np. na podstawie długości kolejki zadań wsadowych. Gdy staje się ona zbyt długa, AutoScaler wydaje polecenie stwórz dodatkowe 2 maszyny wirtualne do 5 już istniejących. Funkcja Rightsizing dostosowuje ich wielkość do potrzeb. Updater dokonuje roll-out’u nowej wersji instalowanego na Google Cloud Platform programu na kolejne maszyny wirtualne. Jednocześnie sprawdza jak program się na nich zachowuje, a w przypadku wykrytych błędów przywraca jego starszą wersję. Funkcja Regional służy zaś do automatycznego rozpraszania pomiędzy wiele stref i przełączania pomiędzy nimi. AutoHealer obserwuje jak program działa. Jeśli zbyt wolno, to przeinstalowuje go, kasując starą kopię i uruchamiając nową. Natomiast funkcja Live Migration wykorzystywana jest w przypadku, gdy fizyczny serwer – na którym stoi maszyna wirtualna – musi zostać wyłączony, np. w celu naprawy. Wówczas instancja ta „przerzucana” jest na inną maszynę fizyczną.

Na Google Cloud Platform tworzone są także rozwiązania dedykowane konkretnym zastosowaniom. Przykładem jest – rozwijany w Polsce – Zync. Rozwiązanie to służy do renderowania filmów i grafik. Dane z dysku użytkownika kopiowane są na platformę Google, na której uruchamiana jest odpowiednia liczba maszyn wirtualnych, a przetworzony plik końcowy kopiowany jest do lokalnego katalogu użytkownika. „Firmy zajmujące się tworzeniem grafiki i filmów nie muszą posiadać po swojej stronie inżynierów. Wszystkiego można dokonać za pośrednictwem udostępnianego przez nas oprogramowania, w tym narzędzi takich jak wtyczki do oprogramowania Maya i innych programów do grafiki 3D. Tego typu narzędzi tworzymy coraz więcej” – podsumowuje Jarek Kuśmierek.

PODZIEL SIĘ

BRAK KOMENTARZY

ZOSTAW ODPOWIEDŹ