# Usługi dodatkowe

# Grupy instancji

Utworzenie grupy i dodanie do niej maszyn pozwala na konfigurację poziomu separacji. Grupy są też wykorzystywane do konfiguracji usług: Autoskalera horyzontalnego oraz Load balancera.

# VM Affinity

Parametr VM Affinity pozwala wpłynąć na rozmieszczanie maszyn wirtualnych w obrębie hosta.

Wybranie wartości minimalnej będzie powodować umieszczenie maszyn na tym samym hoście (co pozwala na zminimalizowanie ewentualnych opóźnień), a maksymalna umieści maszyny jak najdalej od siebie (co powinno zminimalizować możliwość potencjalnej awarii obu hostów równocześnie).

🔗 Jak stworzyć grupy instancji?

# Scheduler

Scheduler jest formą zadania pozwalającego na zaplanowanie wykonania żądanej operacji z wyprzedzeniem bądź też wykonywanie powtarzalnych sekwencjach o określonym czasie.

Z pomocą schedulera można zautomatyzować takie zadania jak włączanie, wyłączanie instancji, zmianę klasy, wykonanie backupu oraz wiele innych.

🔗 Jak dodać scheduler?

🔗 Jak utworzyć cykliczny backup?

# Autoskaler

Autoskaler - jest funkcjonalnością infrastruktury Oktawave pozwalającą na monitorowanie i automatyczne podejmowanie akcji zmiany stanu, parametrów instancji OCI oraz kontenera. Rozróżniane są dwa typy autoskalera, tj. typ wertykalny umożliwiający zmianę parametrów instancji OCI oraz typ horyzontalny właściwy dla kontenera umożliwiający zmianę liczby instancji OCI.

# Autoskaler wertykalny

W locie dodaje bądź ujmuje zasoby obliczeniowe instancji (dokładnie RAM i CPU). Upscaling (czyli dokładnie zasobów) zazwyczaj przebiega bez konieczności restartu instancji. Downscaling (czyli odejmowanie zasobów) wymaga natomiast restartu. W trakcie restartu aplikacja/serwis może być niedostępna, ale też możesz zaplanować cały proces tak, że downscaling może zadziałać tylko w konkretnych godzinach.

Dla przykładu pomiędzy godzinami 7:00 a 23:00 można zezwolić Autoskalerowi wertykalnemu wyłącznie dodawać zasoby. Pomiędzy 23:00 a 7 rano - jeśli jest to uzasadnione - autoskalerowi udzielane jest zezwolenie na ujęcie zasobów, nawet kosztem restartu. Technicznie możesz też wyłączyć możliwość ujmowania zasobów w ogóle, wtedy samodzielnie zdecydujesz, kiedy powrócić do pierwotnej konfiguracji instancji.

Ze względu na konstrukcję obecnych systemów operacyjnych, zmiana klasy instancji OCI w przypadku uruchomionego Autoskalera wertykalnego pomiędzy klasami posiadającymi:

  • 2GB RAM i mniej a 4GB RAM i więcej dla Linuxa
  • 64GB RAM i mniej a 96GB RAM i więcej dla Linuxa
  • 32GB RAM i mniej a 64GB RAM i więcej dla Windows

będzie wymagała restartu instancji. Jest to spowodowane sposobem alokacji pamięci przez system operacyjny.

Jeśli użytkownik odznaczy opcję "Zgoda na wykonanie restartu w godzinach" wówczas zmiana klasy nie będzie mogła zostać zrealizowana i w konsekwencji działanie Autoskalera zostanie wstrzymane. Rozwiązaniem problemu jest albo uruchomienie Autoskalera wertykalnego na instancji o minimalnym typie posiadającym 4GB RAM (w przypadku Linuxa) lub wyrażenie zgody na restart instancji (w trakcie zmiany klasy). Pamiętaj, że to ograniczenie nie dotyczy zmian pomiędzy pozostałymi klasami.

# Autoskaler horyzontalny

Uzupełnienie Autoskalera wertykalnego i jego zadaniem jest klonowanie (tworzenie nowych) instancji w przypadku, jeśli nie ma możliwości już zwiększenia zasobów CPU/RAM na instancji źródłowej (możesz np. określić, że źródłowa instancja nie może konsumować więcej niż 16 GB pamięci). Jego działanie spowoduje, że z jednej instancji z serwisem zostaną utworzone najpierw dwie instancje, później trzy i tak dalej - aż do ustawionego limitu.

To, co jest najważniejsze, to fakt że autoskaler horyzontalny działa w połączeniu z load balancingiem (rozkładaniem ruchu przychodzącego na określone instancje). Czyli jeśli serwis będzie dostępny na co najmniej dwóch (lub więcej) maszynach, to zasadniczo żaden restart ani modyfikacja którejkolwiek z nich nie będą miały wpływu na dostępność serwisu. Co więcej, można tak skonfigurować mechanizm load balancera, aby co 10 sekund sprawdzał czy aplikacja odpowiada na wszystkich instancjach i jeśli którakolwiek z nich zwróci błąd, wówczas load balancer przestanie kierować na nią ruch.

Autoskaler wertykalny reaguje nie wcześniej niż 40 minut od boota/restartu/uruchomienia instancji w krokach co 20 minut, czyli co 20 minut może wykonać akcje dodania/ujęcia zasobów instancji, bazując na raportach wykorzystania pamięci i CPU (reaguje odpowiednio wcześnie). Autoskaler horyzontalny reaguje co 20 minut. Patrząc wg kolejności zwiększania zasobów, najpierw reaguje Autoskaler wertykalny, (zwiększając zasoby dostępne dla instancji), a następnie horyzontalny. Przy zmniejszaniu zasobów jest dokładnie odwrotnie.

Podsumowując, połączenie obu mechanizmów, gwarantuje że w żadnym momencie usługa nie przestanie być dostępna, niezależnie od tego czy zasoby są dodawane czy odejmowane.

# Autoskaler horyzontalny a OPN

W przypadku autoskalera horyzontalnego należy umieścić w OPN jedną instancję niepodlegającą klonowaniu i skonfigurować na niej serwer DHCP. Na instancji, która będzie klonowana ustaw automatyczną konfigurację interface po DHCP. Wyeliminuje to konieczność ręcznego ustawiania adresów IP dla każdej klonowanej instancji z osobna. Adres będzie pobierany przy użyciu DHCP.

Linux https://wiki.debian.org/NetworkConfiguration (opens new window)

Windows https://support.microsoft.com/en-us/help/15089/windows-change-tcp-ip-settings (opens new window)

# ​Logi zdarzeń

W Logach zdarzeń możesz sprawdzić historię operacji zlecanych i wykonanych na poziomie platformy. Mogą być to na przykład operacje utworzenia/skasowania, bądź włączenia/wyłączenia oraz podobne. Dostępne logi ograniczają się do operacji zlecanych w Panelu oraz API. Nie zawierają i z założenia nie mają zawierać zdarzeń wykonywanych w obrębie systemu operacyjnego oraz aplikacji na instancjach.

🔗 Logi zdarzeń