Rewolucyjne wydanie OpenStack 12

Openstack and Containers

Czy pamiętacie, kiedy powstawał OpenStack? Tak, w 2010 roku… Kawał czasu. Od tamtej pory stał się najbardziej popularną chmurą prywatną i hybrydową na świecie. Zaczynał jako „pomoc” przy stawianiu wirtualek dla NASA :-), a dziś? Dziś większość światowych gigantów TelCo to komiterzy tego projektu. Rynek telekomunikacyjny to jeden z największych beneficjentów oprogramowania OpenStack.

Ale zacznijmy od początku. OpenStack co kilka lat ma przełomowe wydania. Rozwój tego produktu jest jednym z najbardziej dynamicznych. Nowe wersje co około sześć miesięcy. Pierwsze wydanie Austin w 2010 roku to tylko Nova i Swift, ale kolejny milowy krok to wydanie Essex z 2012 roku. Wówczas to do platformy dołączył centralny punkt uwierzytelniania w postaci projektu Keystone. Rok później (i dwa wydania produktu później 😉 kolejna rewolucja. Projekt Quantum został zastąpiony Neutronem. Sieć w OpenStack nabrała nowego wymiaru. Najwięksi producenci sprzętu sieciowego zaczęli certyfikować swoje urządzenia na platformę OpenStack. Z tego okresu rozwoju z rozrzewnieniem wspominam wydanie Juno. Bardzo stabilne, łatwe do instalacji i pełne nowych możliwości. Ale przed nami były kolejne przełomowe fale rozwoju OpenStack. Wraz z wydaniem wersji Liberty w 2015 roku pojawił się nowy model instalacji platformy. Był to tzw. TripleO – OpenStack On OpenStack. Założeniem projektu było zrobienie dwóch środowisk – undercloud do zarządzania infrastrukturą i overcloud jako właściwy OpenStack świadczący usługi „dla ludności” 🙂

Przełomowe zmiany w OpenStack

W ciągu tych wszystkich lat rozwoju, do platformy OpenStack dołączały coraz to nowsze projekty, które rozszerzały jego funkcjonalność. Platforma zdobywała nowe rynki wraz z rosnącą popularnością chmur prywatnych i hybrydowych. W grudniu 2017 roku Red Hat wydał kolejną przełomową wersję OpenStack Platform. Wydanie to zostało oparte o wersję Pike. To kolejny kamień milowy w rozwoju tego oprogramowania. Najważniejsze – rewolucyjne zmiany omówię poniżej.

Wykorzystanie projektu KOLLA do dostarczania usług OSP jako kontenerów

Pierwszą z nich jest wykorzystanie projektu KOLLA do dostarczania usług OSP jako kontenerów. Tak, tak. Teraz Nova, Glance, Keystone czy Neutron to już nie usługi instalowane w ramach jakiegoś hosta, ale kontenery.

Openstack and Containers

Overcloud w kontenerach, to genialny pomysł. Mając np.: lukę bezpieczeństwa w jednym z komponentów noda kontrolnego (powiedzmy, że w Nova), możemy podmienić jej kontener na nowy, w bezpieczny sposób, niewpływający na inne serwisy controll nodea. Może się bowiem okazać, że zmiana jakiegoś elementu systemu, którego potrzebuje Nova, by wgrać poprawkę, będzie w kolizji z Glance, czy Keystone. Przy konteneryzacji ten problem znika.

Inne udogodnienia płynące z takiego podejścia to:

  • Niezależność od platformy systemu operacyjnego.
  • Banalne skalowanie w górę i w dół.
  • Atomizacja operacji typu install, patch, upgrade itp.
  • Szybki deployment. Do tej pory instalacja z użyciem HEATa, to była „przygoda” na kilkadziesiąt minut lub godzin – w zależności, jaką infrastrukturalne budowaliście. Dzięki zmianie sposobu instalacji na kontenery cały proces przebiega w kilka minut.
  • Natychmiastowy update. Jeśli w repozytorium pojawi się nowy obraz serwisu, od razu jest pobierany i uruchamiany. Jeśli coś się nie powiedzie, można równie szybko zrobić rollback.
  • „Samouzdrawianie”. Dzięki Kubernetesowi kontenery są pod ciągłą obserwacją Jeśli, któryś z nich zostanie zatrzymany lub ulegnie awarii to Kubernetes natychmiast powoła nowy kontener z zatrzymaną usługą.

Ansible + Container = OpenStack

Odejście od instalatora z użyciem szablonów HEATa na rzecz Ansible

Kolejna rewolucyjna zmiana, to odejście od instalatora z użyciem szablonów HEATa, na rzecz prostszego Ansible. Oczywiście na razie cały czas można jeszcze korzystać z HEATa, a jego szablony są w locie tłumaczone na Ansible. Ale preferowany sposób instalacji od wersji OSP12 to Ansible. Red Hat dostarcza gotowe playbooki, które pomogą nam przy budowaniu środowiska.

Full-Stack Automation with Ansible and OpenStack

Do tej pory HEAT kierował Puppetem, aby budować naszą infrastrukturę OSP. Teraz HEAT kieruje Ansible, żeby osiągnąć ten sam cel. Ansible na poziomie deploymentu środowiska daje możliwości, których do tej pory administratorzy nie mieli. Zobaczcie filmik

Szersze użycie TSL i poprawa bezpieczeństwa

Kolejna zmiana to ewolucja, nie rewolucja. Chodzi mianowicie o kwestie bezpieczeństwa. Ten problem zawsze był ważny dla klientów, ale w tej wersji wreszcie udało się pójść dużo dalej niż w dotychczasowych wydaniach. W wydaniu Pike większość wewnętrznych serwisów platformy porozumiewa się kryptowanymi kanałami. Wreszcie TLS zagościł na dobre w naszej wewnętrznej infrastrukturze. Szersze użycie TLS zainspirowało firmę Red Hat do wydania specjalnego podręcznika „Comprehensive Security Guide” dla wydania OSP12, w którym omówione są najlepsze praktyki i koncepcje ich wykorzystania – wszystko po to, aby poprawić bezpieczeństwo OpenStack Platform. W tym zakresie społeczność i Red Hat współpracuje z największymi międzynarodowymi agencjami, takimi jak: FedRAMP (USA), ETSI (Europa), and ANSSI (Francja).

Dodanie do projektu nowej wersji Open vSwich 2.7 współpracującego z Data Plane Development Kit (DPDK) 16.11

Ostatnim wielkim krokiem w przód jest dodanie do projektu nowej wersji Open vSwich 2.7 współpracującego z Data Plane Development Kit (DPDK) 16.11. Dzięki temu połączeniu mamy niesamowity skok wydajności sieci. Branża TelCo na pewno się ucieszy z tej nowości. Od dawna bowiem czekano na takie elementy jak: jumbo frames, connection tracking, link bonding, czy PCI passthrough. Dostajemy łatwy dostęp pakietów do i z user space, a przy tym zmniejszamy zapotrzebowanie na CPU, mamy integrację z SDN i możemy robić migrację na żywo. Zobaczcie, jak wędrują pakiety w różnych połączeniach technologii.

SDN fundamentals for NFV OpenStack and Containers Red Hat

Na zakończenie dodam, że przejście z wersji niekontenerowej, do wersji opartej o kontenery jest w pełni automatyczne i robione przez OSP Directora. Czyli robiąc upgrade z OSP11 do OSP12, director zadba o zmianę serwisów na kontenery bez waszego udziału.

OpenStack Platform to oprogramowanie, które prócz stabilności gwarantuje nam podążania za najnowszymi osiągnięciami technologii. Każdy nowy pomysł, który powstaje jako społecznościowe wydanie RDO, po „wygrzaniu” się i okrzepnięciu w środowisku jest przenoszony do wydania komercyjnego. Dzięki temu nie musimy latami czekać na nowości. Myślę, że OpenStack jeszcze nie raz nas zaskoczy. A tymczasem miłego testowania.

Tags

top