Virtual data center: jak odciążyć własne data center maszynami w Azure

Segmentacja sieci jest taka sama, a agenty wymagane na maszynach, np. do skanowania czy DLP, są wpisane w szablon, więc każda nowa maszyna ma je od początku.

Nie, jeśli Twoje obecne narzędzie wspiera Azure. Gdy obsługuje też odtwarzanie maszyn w Azure, a licencja na to pozwala, możesz nim migrować: odtwarzasz maszynę z backupu w chmurze szybciej niż przez Azure Migrate, a zależnie od podejścia nawet bez przestoju.

Tylko jeśli wcześniej zaakceptujesz politykę automatycznej zmiany rozmiaru. Inaczej właściciel przewymiarowanej maszyny dostaje alert i sam ją zmniejsza.

Mikołaj Szczerbicki: Dużym problemem jest brak przewidywalności kosztów, jeżeli chodzi o rozbudowę data center.

Łukasz Kałużny: Chciałbym zaproponować, że odciążamy lokalne data center z mniej krytycznych workloadów. Mamy bardzo błędne przekonanie, że to musi chodzić 24 godziny na dobę. To jest oszczędność 71% względem cennika przez to, że maszyna jest wyłączona. Nie migrujemy wszystkiego, tylko to, co nam być może przeszkadza albo mogłoby bezpiecznie biznesowo, bez dużego ryzyka zwolnić zasoby lokalne.

Mikołaj Szczerbicki: Cześć. Witamy w Powered by Protopia. Nazywam się Mikołaj Szczerbicki i dzisiaj jest ze mną Łukasz Kałużny.

Łukasz Kałużny: Dzień dobry.

Mikołaj Szczerbicki: Łukasz, widzę na rynku duży problem związany z data center. Dużo organizacji wciąż korzysta z rozwiązań on-premises, ze względu na polityki bezpieczeństwa albo po prostu takie mają standardy. Są to rozwiązania albo w stu procentach on-premises, albo hybrydowe. Myślę, że kierunek „to the cloud” u wszystkich trochę ostygł. Natomiast używamy coraz więcej zasobów i naturalne jest, że data center trzeba rozbudowywać. Dużym problemem jest brak przewidywalności kosztów takiej rozbudowy. Dołączyłbym do tego jeszcze problem z terminowością.

Łukasz Kałużny: Tak, koszty w tym momencie wystrzeliły…

Mikołaj Szczerbicki: Chciałoby się powiedzieć, że nawet w kosmos.

Łukasz Kałużny: Tak. Część z Was prawdopodobnie wie po ofertach, jak krótko są ważne i o jakie rzędy wielkości w niektórych miejscach urosły.

Mikołaj Szczerbicki: Dokładnie. Skoro my widzimy ten problem, widzi go wiele organizacji i często słyszymy dyskusje na ten temat, to czy masz pomysł, jak takim organizacjom pomóc?

Łukasz Kałużny: Wróciłbym do pierwszego scenariusza, w którym przedstawiano chmurę, czyli do chmury jako dodatkowego źródła mocy obliczeniowej, które odciąża lokalne data center.

Mikołaj Szczerbicki: Brzmi dobrze.

Łukasz Kałużny: Nie chodzi tu o rewolucję, że przeniesiemy, tak jak powiedziałeś, wszystko do chmury i zrobimy lift and shift wszystkich maszyn wirtualnych. Chciałbym raczej zaproponować, że odciążamy lokalne data center z mniej krytycznych workloadów. Czyli na przykład z mniej ważnych biznesowo aplikacji backoffice’owych i ze środowisk developerskich, nieprodukcyjnych, testowych, wszystkiego, co określamy nieprodukcją. To prawdopodobnie jest bardzo duża wygrana.

Mikołaj Szczerbicki: Czyli nie chcesz po raz n-ty przekonywać klientów, do których pewnie dzwoniło mnóstwo dostawców, żeby przemigrowali się do chmury w całości. Chcesz zaproponować sprytne rozwiązanie.

Łukasz Kałużny: Odciążenie, tak.

Mikołaj Szczerbicki: Odciążenie.

Łukasz Kałużny: I nazywamy ten koncept Virtual Data Center.

Mikołaj Szczerbicki: No to teraz musisz nam rozłożyć na czynniki pierwsze, czym to dokładnie jest.

Łukasz Kałużny: Na chmurę patrzymy zwykle przez pryzmat aplikacji, PaaS-ów, SaaS-ów i IaaS-ów. W Virtual Data Center chodzi o to, żeby potraktować chmurę, w naszym przypadku Azure, jako przygotowaną, współdzieloną przestrzeń do stawiania maszyn wirtualnych, wyspecyfikowaną i wystandaryzowaną. Mówimy tu o koncepcie landing zone jako wystandaryzowanego elementu. Chodzi o to, żeby dostosować landing zone do automatycznego powoływania maszyn wirtualnych i współdzielenia zasobów pod spodem na subskrypcji. Dzięki temu osiągamy lepszy efekt kosztowy i odciążamy lokalne data center.

Co robimy w Virtual Data Center? Przygotowujemy zestawy subskrypcji w postaci landing zone. Przygotowujemy konfigurację sieciową tak, żeby odpowiadała segmentacji, którą wykorzystujemy w lokalnym data center, czyli podziałowi na VLAN-y i strefy. Potem przygotowujemy całą część governance’ową, czyli polityki bezpieczeństwa, tagi, budżety i alerty.

Potem pojawia się część związana z maszynami wirtualnymi, czyli infrastructure as code w postaci skryptów albo Terraformu, w zależności od preferencji, oraz szablony maszyn. Dzięki nim da się powtarzalnie i łatwo tworzyć kolejne maszyny wirtualne zgodnie z naszymi wymaganiami, takimi samymi jak lokalnie. Na przykład z preinstalowanymi agentami do skanowania, do DLP, w zależności od tego, co mamy, albo do monitoringu. Do tego dochodzi warstwa infrastrukturalna, czyli backupy: natywny backup w postaci Azure Backup, preferowany przez nas Veeam albo rozwiązanie third party, które już u klienta istnieje i wspiera Azure.

Mikołaj Szczerbicki: Czyli jest to dalej data center, tylko postawione w, jeżeli jest dobrze zrobionym oczywiście, środowisku chmurowym, które daje nam dużą elastyczność w tym zakresie.

Łukasz Kałużny: Tak, dokładnie, elastyczność. I to, że nie zastanawiamy się, jaka usługa, jaka grupa zasobów, co mamy zrobić. Dostajemy bardzo proste wytyczne: tak wstawiamy kolejną maszynę wirtualną albo ją migrujemy, żeby odciążyć lokalne data center. A crème de la crème, które możemy zaproponować na koniec, to wpięcie się do systemu ticketowego i przygotowanie formularzy, które pozwalają nawet na self-service przy stawianiu takich maszyn wirtualnych.

Mikołaj Szczerbicki: Dobrze, wytłumaczyłeś, czym jest Virtual Data Center. Ale zaczęliśmy od tego, że najbardziej nieprzewidywalne są dziś koszty budowy data center on-premises. Powiedz mi coś o kosztach Twojego rozwiązania.

Łukasz Kałużny: Dlaczego mówiłem o środowiskach niekrytycznych, a w szczególności nieprodukcyjnych? Bo mamy bardzo błędne przekonanie, że to musi chodzić 24 godziny na dobę. To jest najciekawsza rzecz, jeśli patrzymy, jak możemy oszczędzić. Automatyczne włączanie i wyłączanie maszyn poza godzinami pracy, czyli system na maszynach wirtualnych środowisk nieprodukcyjnych jest włączony, powiedzmy, między 8 a 18. To jest oszczędność 71% względem cennika, bo płacimy tylko za czas, gdy maszyna jest włączona. Wtedy ona nie mieli powietrza. To jest 200, około 210 godzin zamiast uśrednionych 730 godzin miesięcznie.

Mikołaj Szczerbicki: No to różnica jest duża.

Łukasz Kałużny: Tak. Wziąłem cennik najpopularniejszej maszyny wirtualnej, powiedzmy Intela albo AMD. Za jej moc obliczeniową płacimy miesięcznie w okolicach 160–170 dolarów, a jeśli jest wyłączana, schodzimy do 46–51 dolarów. Jeżeli coś ma działać cały czas, na przykład niekrytyczna aplikacja biznesowa, to pojawiają się savings plans albo rezerwacje dla rzeczy, które chodzą 24 godziny na dobę. Tu oszczędność jest mniejsza, bo maszyna pracuje cały czas, i wynosi od 45 do 61%, które można uzyskać odpowiednim setupem licencji po stronie Azure.

Mikołaj Szczerbicki: Czyli te, które w czasie, nazwijmy to, spoczynku nie są wykorzystywane, mają suwak ściągnięty w dół?

Łukasz Kałużny: Tak, są po prostu wyłączane, ich nie ma. Płacimy wtedy za dysk, bo za dysk płacimy oddzielnie, tej ceny tutaj nie ujmowałem.

Mikołaj Szczerbicki: A te, o których wiemy, że będą działać cały czas, też mogą być trochę tańsze, bo można skorzystać z rezerwacji.

Łukasz Kałużny: Tak, z benefitów w postaci planów oszczędności, czyli savings plans, albo rezerwacji, w zależności od potrzeb. I to właśnie standaryzacja pozwala uzyskać. Kolejna rzecz: jeżeli to będą maszyny windowsowe, mamy Azure Hybrid Benefit, który pozwala używać licencji zarówno on-premises, jak i w chmurze. Chodzi o licencje Windows Server czy SQL Server. Jeżeli jest aktywna umowa z Software Assurance, to w zależności od typu licencji można ją wykorzystać w chmurze. To kolejny benefit: ponownie wykorzystujemy licencje, które mamy lokalnie.

Mikołaj Szczerbicki: A w jaki sposób te koszty są monitorowane?

Łukasz Kałużny: Z jednej strony są standardowe mechanizmy FinOpsowe chmury, czyli budżety i Azure Advisor. Oprócz tego dokładamy od siebie warstwę naszych alertów i skryptów, które monitorują w szczególności niewykorzystane, zmarnowane zasoby. Bardzo często zdarzają się też przewymiarowane zasoby, czyli dla bezpieczeństwa wzięto za dużą maszynę wirtualną. Monitorujemy to i alertujemy, mamy skrypty do wykrywania. Przy takim setupie przychodzimy z gotowym zestawem skryptów, żeby wykrywać takie rzeczy cyklicznie i od razu podejść do tego FinOpsowo. Jest to od razu wbudowane w platformę.

Z drugiej strony, jeżeli jest akceptacja na agresywniejsze podejście, to na przykład w cyklach tygodniowych badamy metryki zużycia i automatycznie albo po wcześniejszej informacji robimy resize’y. Albo alertujemy właścicieli, że muszą przeskalować maszyny w dół, albo, w agresywniejszym podejściu, tworzymy politykę, która zmniejsza liczbę core’ów. Bardzo często CPU nie jest wykorzystywany, więc przykładowo zamiast 4 core’ów dajemy maszynie 2, zostawiając tyle samo RAM-u. Na jednej maszynie, która chodzi 24 godziny na dobę, to jest 177 dolarów versus 117 dolarów. To są przypadki, które też trzeba tu rozważać.

Mikołaj Szczerbicki: To, co powiedziałeś, jest bardzo ważne. Virtual Data Center to nie jest rzecz zaprojektowana z góry, która potem zostaje do samodzielnego utrzymania i zgadywania, czy jest dobrze, czy nie. Od razu dostajemy cały standard monitoringu, czyli zbudowany FinOps.

Łukasz Kałużny: Tak, od razu, żeby optymalizować koszty.

Mikołaj Szczerbicki: To jest niesamowicie istotne, bo data center, nawet wirtualne, ma się zmieniać. Po to jest, żeby było elastyczne. Liczba maszyn wirtualnych też będzie prawdopodobnie rosła.

Łukasz Kałużny: Kiedy to mamy, oprócz stawiania nowych rzeczy będziemy chcieli też migrować, żeby odciążyć lokalne data center. Nowe rzeczy stawiamy szybko, skryptami. Po zbudowaniu platformy jest to dostępne od razu. Do migracji mamy dwa podejścia.

Pierwsze: bierzemy istniejące maszyny i narzędziem Azure Migrate, które jest częścią Azure, robimy ocenę i migrację z VMware, Hyper-V albo innych platform. Przenosimy i konwertujemy maszyny wirtualne. Wymaga to oczywiście przestoju, bo trzeba przesłać dane, ale pozwala sprawnie przenieść workloady w nowe miejsce.

Drugie: jeżeli narzędzia do backupu się integrują, a świetnym przykładem jest Veeam, to możemy odzyskać maszynę wirtualną z backupu u dostawcy chmurowego, w tym przypadku w Azure, w naszym Virtual Data Center. Jeżeli mamy istniejące backupy, nasze narzędzie to wspiera i mamy na to licencję, można to wykorzystać do migracji.

Mikołaj Szczerbicki: Czyli wtedy migracja jest dużo szybsza?

Łukasz Kałużny: Tak, albo bezprzerwowa, w zależności od podejścia.

Mikołaj Szczerbicki: Dobrze, omówiłeś podejście migracyjne, które może być dwojakie. Powiedz mi w takim razie, jak wygląda proces wdrożenia, jeżeli ktoś jest przekonany, że to dobra droga?

Łukasz Kałużny: Od razu powiem o czasie, bo to też jest istotne, a on jest zaskakująco krótki: od 4 do 8 tygodni do uzyskania działającego produktu, gotowego do wykorzystania.

Mikołaj Szczerbicki: Pewnie się nie pomylę, jeśli powiem, że kto dziś chciałby rozbudować data center on-premises, ten na ten rok raczej nie może liczyć.

Łukasz Kałużny: To zależy od wielkości zamówienia. Jak wygląda proces? Najpierw jest faza rozeznania, discovery, w której sprawdzamy, czy jest już Azure, jak wyglądają koncepcje sieci i jakie są wymagania. Robimy to w formie warsztatów, żeby zebrać wszystkie wymagania. Następnie projektujemy rozwiązanie, czyli dostosowujemy nasz wystandaryzowany kod infrastructure as code do potrzeb klienta.

Potem zaczynamy główną fazę, czyli setup i konfigurację całego środowiska. Dostajemy subskrypcję, przygotowujemy całą część sieciową, testujemy skrypty i szablony stawiania maszyn. Wdrażamy polityki bezpieczeństwa, automatyczne tagowanie, budżetowanie i backupy, a także podejście do tożsamości i nadawania dostępów. Kiedy to mamy, jesteśmy już gotowi na nowe maszyny wirtualne. Ewentualnie dochodzi crème de la crème w postaci procesu self-service. Ale po głównym setupie możemy już wystawiać nowe maszyny.

Potem jest dodatkowa część, czyli pilotażowe migracje, żeby zacząć odciążać. Jeżeli pilotaże się udadzą, można zacząć na większą skalę migrować mniej krytyczne systemy i faktycznie odciążać data center, w zależności od potrzeb: czy chodzi o rozbudowę, czy o zabranie części obciążenia.

Mikołaj Szczerbicki: Łukasz, czy mogę Cię na koniec prosić o bardzo krótkie podsumowanie?

Łukasz Kałużny: Koncept Virtual Data Center to wystandaryzowanie subskrypcji, w naszym przypadku azure’owych landing zone, po to, żeby przygotować je pod hostowanie wielu maszyn wirtualnych w sposób współdzielony. Uzyskujemy efekt synergii, bo nie rozrzucamy zasobów, tylko mamy je w jednym miejscu. Do tego od strony kosztowej dochodzi pełny proces FinOpsowy, żeby nie marnować zasobów, na przykład przez wyłączanie maszyn wirtualnych środowisk developerskich i testowych. I cały cykl życia, który jest potrzebny, gdy maszyna pojawi się na platformie, postawiona od nowa albo przemigrowana.

Mikołaj Szczerbicki: Czyli jest to rozwiązanie dla użytkowników on-premises, żeby odciążyć ich bieżące data center.

Łukasz Kałużny: Z rzeczy niekrytycznych.

Mikołaj Szczerbicki: Dokładnie.

Łukasz Kałużny: Nie migrujemy wszystkiego, tylko to, co nam być może przeszkadza albo mogłoby bezpiecznie biznesowo, bez dużego ryzyka zwolnić zasoby lokalne.

Mikołaj Szczerbicki: Łukasz, bardzo Ci dziękuję za dzisiejszą rozmowę. Dziękujemy wszystkim i do zobaczenia w następnych odcinkach.

Łukasz Kałużny: Na razie, dzięki.