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>”
Polisa jest domyślnie ustawiona na poziomie datastore.
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.
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ć!
Dodam Cię do listy mailowej, z której możesz wypisać się w dowolnym momencie (jeden klik.) | Polityka Prywatności