Obniżyć “Managed Storage Policy” w VMware on AWS ? i dlaczego NIE!

Wprowadzenie

 

VMware on AWS to usługa w modemu SaaS, którą można wykupić na żądanie z taką konfiguracją jaką daje Vendor. To ma swoje plusy jak i minusy ale o tym kiedy indziej. Dziś chciałbym poruszyć krótko temat zmiany storage policy na platformie  VMware on AWS i jakie idą za tym konsekwencje.

Storage polisa, która domyślnie nazywa się “MC Workload Storage Policy – <cluster name>”

 

VM Storage Policy UI, VMC Workload Storage Policy - Cluster-1 Selected.

 

Polisa jest domyślnie ustawiona na poziomie datastore.

 

WorkloadDatastore Default Storage Policy set to VMC Workload Storage Policy - Cluster-1

 

W miarę skalowania klastra usługa zapewnia, że polityka specyficzna dla klastra pozostaje zgodna z wymaganiami umowy SLA usługi. W razie potrzeby zatem, automatycznie rekonfigurując ustawienia zasad i wszelkie powiązane z nimi dane.

 

 

Możliwe ustawienia polisy

Konfiguracje zostały obrane na bazie SLA jakie VMware/AWS określa dla swojej usługi. Service Level Agreement for VMware Cloud™ on AWS 

Dla standardowego klastra (single-AZ)

Liczba hostów Konfiguracja polisy
5 lub mniej możliwa 1 awaria – raid-1 (mirroring , FTT-1)
6

 

Dla rozciągniętego klastra

Liczba hostów Konfiguracja polisy
Any Dual Site Mirroring
1 Failure – Raid-1 (mirroring)

 

Rozszerzanie klastra tzw. Scale-out

Po dodaniu hosta do klastra usługa weryfikuje ustawienie zasad. W razie potrzeby ponownie sama skonfiguruję odpowiednią polisę. Ten proces, choć automatyczny, może być monitorowany przez vCenter.

 

Scale up SDDC and the Integrated Policy is updated as needed.

 

Podobny automat chodć bardziej złożony działa przy usuwania hosta z klastra.  Nie mniej jednak potrzeba ustrzymania SLA jest monitorowana i może się tak zdarzyć iż przyjdzie nam do głowy potrzeba ręcznego obniżenia redundantności w polisie z różnych powodów.

Musimy być wówczas być świadomi tego iż w razie awari hosta dostawca wówczas nie będzie odpowiadał za niedostępność usługi jeśli jakas nasza maszyna wirtualna nie miała rozproszonych obiektów na dyskach VSANowych.

 

Monitoring zgodności polisy

Dodatkowo dostajemy także maila w postaci raportu od VMware informujący nas o braku zgodnosci konfiguracji z przewidywanym SLA.

 

Dalej tylko przypominane że mamy do wyboru 2 opcje. Albo wrócimy do dedykowanej konfiguracji z SLA albo VMware nie będzie odpowiadał za szkody w przypadku awarii.

 

Dlatgo też należy z rozwagą świadmością tego co sie robi modyfikować ustawienia usługi SaaS nawet jesli daje ona taką możliwość.

Jeśli chciałbyś być na bieżąco i budować swoją wiedzę razem ze mną w tematach IT dodaj się do listy mailowej ? TUTAJ ? . Co jakiś czas będę podsyłał Tobie informacje co się dzieje na blogu i w świecie cloud computingu, którym także się zajmuję. Masz jakieś pytania lub myślisz że moglibyśmy zrobić wspólny projekt razem ? daj znać!

 

Informacje o nowych artykułach, świecie wirtualizacji i "cloud computingu" prosto na Twojego maila:

Dodam Cię do listy mailowej, z której możesz wypisać się w dowolnym momencie (jeden klik.) | Polityka Prywatności