Sektor finansowy w kontenerach?

Są typy projektów, które lubimy i „czujemy” oraz takie, których wolimy unikać. Doradztwo przy projektach związanych z rozwojem infrastruktury IT należy do tych, które sprawiają mi największą frajdę, szczególnie, gdy mogę jednocześnie współpracować z fantastycznym zespołem specjalistów z inleo. Przybliżę Wam mały wycinek naszej pracy doradczej, którą realizowaliśmy ją dla jednej z największych firm sektora finansowego w Polsce.

Przyszło nam się mierzyć, nie tylko z ograniczeniami natury biznesowej czy technicznej, ale także prawnej, związanej ze specyfiką sektora bankowego. Warto też zaznaczyć, że zamawiający zatrudnia zespół wysokiej klasy specjalistów z praktycznie każdej dziedziny IT, który na bieżąco weryfikował i testował nasze propozycje.

Skupię się na dwóch obszarach tego projektu, które obejmują fragmenty zagadnień compute oraz storage.

Technologiczne aspekty projektu musiały wpisywać się w ogólnie przyjętą przez klienta strategię rozwoju systemów teleinformatycznych rozbudowy aplikacji. Zaczynaliśmy pracę, mając postawione jasne technologiczne i biznesowe cele, jakie należało osiągnąć. Wśród najważniejszych technologicznych założeń należy wymienić:

1. Dążenie do unifikacji wewnętrznych usług poprzez ich standaryzację i kreowanie ich za pomocą zdefiniowanych w katalogu elementów infrastruktury i aplikacji.
2. Dążenie do dalszej mikrosegmentacji serwisów poprzez modularyzację ich budowy oraz odejście od natywnego wykorzystywania maszyn wirtualnych na rzecz konteneryzacji. W tym obszarze zamawiający preferował wykorzystanie klastrów Kubernetes, lecz dopuszczał on też inne rozwiązania.
3. Docelowe rozwiązanie konteneryzacyjne ma działać w lokalnych centrach zamawiającego, ale w przyszłości powinno pozwalać na przenoszenie aplikacji na nim działających lub ich rozciąganie do chmury publicznej bez wprowadzania istotnych zmian w budowie aplikacji czy samego klastra.
4. Architektura powinna zapewniać elastyczność w budowaniu rozwiązań w zależności od specyficznych wymagań projektu, zespołu czy aplikacji. Jednocześnie nie może być mowy o żadnych kompromisach w obszarach bezpieczeństwa i redundancji czy odporności na awarie.
5. Zarządzanie infrastrukturą powinno być w miarę możliwości całkowicie zautomatyzowane, wpisywać się w przyjęty model Continuous Deployment oraz uwzględniać wewnętrzne standardy rozliczania kosztów usług.  

Realizując projekt widzieliśmy już jakie są preferencje naszego klienta co do technologii czy kierunku, w którym chciałby rozwijać swoją infrastrukturę, co nie znaczy, że skupiliśmy się jedynie na dopracowaniu jego wizji. Wręcz przeciwnie! Każdy z pomysłów był poddawany gruntownej analizie i uzupełnieniom o dodatkowe propozycje.

Konteneryzacja

https://lelusz.comblog/docker-podstawy/

W zaproponowanym rozwiązaniu platformę compute dla aplikacji stanowią kontenery, a dokładniej klastry Kubernetes. Nie są one jednak uruchamiane natywnie na poszczególnych hostach, lecz wewnątrz maszyn wirtualnych. Rozwiązanie takie pozwala łączyć ze sobą pozytywne aspekty zarówno wirtualizacji jak i konteneryzacji. Ważnym aspektem w tym projekcie jest także zapewnienie zgodności z uwarunkowaniami prawnymi dla sektora finansowego w Polsce. Wirtualizacja pozwala na stałe przepisanie zasobów maszyny wirtualnej do konkretnej aplikacji, projektu czy departamentu. Zapewniona jest w ten sposób, izolacja zasobów sprzętowych dla każdej aplikacji, w każdym z centrów przetwarzania danych, w każdej ze stref bezpieczeństwa. Mechanizmy te są dobrze znane, udokumentowane i akceptowane przez instytucje nadzoru finansowego, zatem ich wykorzystanie stanowi podstawę bezpieczeństwa i pozytywnego przejścia niezbędnych audytów. Jednocześnie wykorzystywane są wszystkie zalety mikrosegmentacji, które daje konteneryzacja.

Dlaczego Kubernetes?

https://lelusz.comblog/kubernetes-1/

Jako system orkiestracji zapewnia on możliwość wdrażania aplikacji w oparciu o pody, serwisy (w tym mikroserwisy) i całe deploymenty. Zapewnia on zaawansowany mechanizm skalowania i wysoką dostępnością aplikacji na nim uruchomionych. Nie bez znaczenia jest też fakt, że jest to natywnie dostępny system Konteneryzacji we wszystkich wiodących usługach chmury publicznej – Azure Kubernetes Services (AKS) czy Amazon Elastic Kubernetes Service (EKS).

W opisywanym projekcie, ze względów bezpieczeństwa przyjęto założenie, że klastry Kubernetes nie są rozciągane pomiędzy centrami danych. Jeżeli aplikacja logicznie ma być pomiędzy nie rozciągnięta, to powoływane są niezależne klastry zarówno w każdym z centrów przetwarzania danych czy chmurze publicznej. Jednocześnie w przyszłości możliwe jest rozciągnięcie klastrów, gdyby wymagania biznesowe i techniczne uległy zmianie.

Kolejnym ważnym założeniem, uwzględnionym w naszej propozycji, jest przyjęcie modelu Immutable Infrastructure.

Polega on na tym, że po powołaniu do życia infrastruktury, zarówno zwirtualizowanej, jak i skonteneryzowanej, nie dokonuje się ich modyfikacji. Oznacza to, że w przypadku awarii lub aktualizacji, uruchamia się nowe klastry Kubernetes , a następnie usuwa stare. Takie podejście pozwala na wprowadzenie modelu opisywanego jako Chaos Engineering, w tym, przede wszystkim, metodologii Choas Monkey i Chaos Testing.

Planowana platforma konteneryzacyjna, miała być oparta o infrastrukturę zapewniającą odpowiednią redundancję warstwy kontrolnej (control plane).

W przygotowanej koncepcji, każdy klaster Kubernetes zarządzany jest przez minimum trzy węzły z zachowaniem zasady nieparzystości węzłów zarządzających, celem zapewnienia kworum. Samo etcd, czyli kluczowy komponent pozwalający zachować stan klastra oraz jego konfigurację, skonfigurowany zostanie w modelu Stacked etcd, w którym kontener obsługujący magazyn etcd uruchamiamy jest w każdym z węzłów tworzących warstwę control-plane. Rozwiązanie takie zmniejsza liczbę węzłów, którymi trzeba zarządzać w ramach klastra. Wymaga to jednak synchronizacji danych pomiędzy węzami, aby zapewnić spójność przechowywanych informacji. Z punktu widzenia wymogów bezpieczeństwa jest to jednak rozwiązanie preferowane – przestrzeń dyskowa dla etcd zawiera się w przestrzeni dyskowej wskazanego węzła klastra.

Wniosek?

Budowa infrastruktury w oparciu o Kubernetes bardzo dobrze wpisuje się w strategię naszego klienta pozwalającą na tworzenie katalogu usług w swojej infrastrukturze, czyli zestawu klocków, z których następnie budowane są aplikacje oraz powiązanych z nimi zestawu niezbędnych działań konfiguracyjnych na infrastrukturze teleinformatycznej. Klocki te, w dalszej przyszłości, pozwalają na elastyczne alokowanie zasobów, odporność na awarię, a także szacowanie kosztów, które muszą zostać poniesione na wdrożenie i utrzymanie aplikacji.

Storage

Zarówno wirtualizacja jak i konteneryzacja niosą za sobą konkretne wymagania dotyczące rozwiązań storage.

W realizowanym projekcie rekomendowaliśmy użycie oprogramowania NetApp Trident.

Jest to rozwiązanie open-source zaprojektowane od podstaw, aby pomóc spełniać specyficzne wymagania dotyczące trwałości aplikacji kontenerowych. Trident dostarcza nie tyle dostęp do przestrzeni dyskowej, co interfejs tłumaczący skomplikowane wymagania kontenerów i działających w nich aplikacji, w zautomatyzowaną i zorganizowaną odpowiedź infrastruktury. Co ważne, oprogramowanie obsługuje systemy do zarządzania danymi znane z lokalnych centrów przetwarzania danych, takie jak ONTAP, Element czy SANtricity, ale także usługę Azure NetApp Files, czy Cloud Volumes w AWS. Integracja z Kuberetes realizowana jest przez odpowiedni plugin.

Działanie NetApp Trident w Kubernetes opiera się o trzy podstawowe rodzaje obiektów opisujących pamięci masowe i operacje:

• Persistent Volume (PV) – opisują sposób połączenia z urządzeniami pamięci masowej za pomocą NFS lub iSCSI. Zawierają takie parametry jak pojemność, typ dostępu, protokół czy politykę.
• Persistem Volume Clain (PVC) – to żądanie dostępu do zasobów pamięci generowane przez aplikację. Zawiera co najmniej informacje o rozmiarze i trybie dostępu.
• Storage Class – to określenie zdefiniowanej przez administratora klasy pamięci na podstawie predefiniowanych właściwości.

1. Aplikacja tworzy PVC zgodnie z specyfikacją Storage Class
2. Trident zostaje poinformowany o zapotrzebowaniu
3. Trident tworzy zasób dyskowy
4. Trident tworzy PV
5. Kubernetes tworzy powiązanie z PV I PVC

Kubernetes na żądanie aplikacji zdefiniowane w PVC przypisuje jej PV, który pasuje do określonych w PVC wymagań. Sama pamięć typu storage nie jest podłączona do węzłów Kubernetes aż do momentu zainicjowania poda. Po utworzeniu instancji kontenera na hoście kubelet, montuje urządzenia magazynujące bezpośrednio w kontenerze.

NetApp ma dodatkową zaletę – pozwala na uruchomienie wirtualnej instancji macierzy w chmurze publicznej, umożliwiając tym samym, proste przenoszenie danych pomiędzy lokalnymi instalacjami w centrum przetwarzania danych a cloudem.

Administrator uzyskuje jednolite narzędzie do zarządzania zasobami dyskowymi dla wszystkich środowisk. Takie rozwiązanie wpisuje się nie tylko w wymagania wysokiej dostępności, lecz także długoterminowej strategii tworzenia hybrydowych rozwiązań opartych, zarówno o lokalne centra przetwarzania danych, jak i chmurę publiczną.

Podsumowując:

Świat aplikacji niewątpliwie zmierza w kierunku mikrosegmentacji realizowanej, między innymi poprzez konteneryzację. Infrastruktura teleinformatyczna musi podążać za tymi zmianami. Aplikacja nie działa przecież zawieszona w próżni, a samej infrastruktury nie budujemy by stała bezczynnie. Konteneryzacja stawia przed architektami i administratorami zupełnie nowe spektrum wyzwań.

W tym artykule ledwo liznęliśmy czubka góry lodowej.