W pracy zajmuję się wieloma sprawami i chociaż sam o sobie mówię „Aktywista ds. DevOps”, oficjalnie zajmuję w Dynatrace stanowisko Dyrektora ds. partnerów strategicznych. W związku z tym odpowiadam za działania zespołu specjalistów z całego świata, który współpracuje ściśle z partnerami strategicznymi naszej firmy, m.in. AWS, Microsoft, Google, Pivotal czy Red Hat. Wszystkich naszych klientów dotyczą — i dlatego też często pojawiają się w naszych rozmowach — tematy migracji do chmury, modernizacji aplikacji, rozbijania monolitu czy też przejście do chmury hybrydowej. Klienci są zazwyczaj zainteresowani jednym aspektem — W jaki sposób Dynatrace może pomóc zmniejszyć ryzyko takiego przejścia, przyspieszyć je i pomóc w generowaniu zysków w związku ze zmianą platformy na chmurę?

W ramach warsztatów technicznych, jakie prowadziłem dla jednego z naszych partnerów strategicznych, zajmujących się działaniami w chmurze, przygotowałem prezentację, która stanowi odpowiedź dokładnie na to pytanie. Omawiam w niej najważniejsze przykłady tego, w jaki sposób Dynatrace może przyczynić się do poprawy planowania, wykonania i optymalizacji projektów związanych z przenoszeniem danych do chmury. Na tym blogu postaram się przedstawić krótko założenia wspomnianej prezentacji, co — mam nadzieję — pozwoli czytelnikom zwizualizować własną migrację do chmury i przeprowadzić ją z powodzeniem.

Zanim jednak przejdę do rozważań dotyczących migracji, muszę przedstawić proces zbierania danych, dzięki którym cały proces przebiegnie sprawniej — to właśnie zdecydowanie wyróżnia rozwiązanie OneAgent na tle innych.

Tajny składnik nr 1 — rozwiązanie Dynatrace OneAgent

Wiele narzędzi do migracji danych do chmury nie korzysta z żadnych agentów. To niewątpliwie ułatwia wdrożenie, ale — jak można się przekonać, studiując moje relacje z klientami — odpowiada na zaledwie ułamek pytań związanych z migracją. I dlatego właśnie firmy zajmujące się planowaniem migracji korzystają z Dynatrace.

Dynatrace łączy w sobie wykorzystanie agentów z podejściem, które się do nich nie odwołuje. „Tajny składnik” tego rozwiązania to Dynatrace OneAgent (zapraszam do obejrzenia tutorialu na YouTube z serii Performance Clinic prowadzonego przez naszego głównego architekta oprogramowania Helmuta Spiegla). Tym razem reklama mówi prawdę. To rzeczywiście jeden agent, którego instaluje się na fizycznym lub wirtualnym hoście, stawia jako operatora platformy Kubernetes lub OpenShift, uruchamia za pośrednictwem platform Bosh, Ansible, Puppet, Chef… Po uruchomieniu agent przekazuje do interfejsu Dynatrace Smartscape API informacje o zależnościach, przeprowadza kompleksowe śledzenie transakcyjne, przechwytuje dzienniki i zbiera szczegółowe dane dotyczące wydajności i metryk systemu:

Dynatrace OneAgent: Jeden agent pracujący na wszystkich platformach i dostarczający dane zależności, śledzący, zbierający dzienniki i metryki.

Gdy mamy przeprowadzać migrację, po prostu uruchamiamy agenta Dynatrace OneAgent w istniejącej infrastrukturze. Przechwytywanie danych i wykrywanie istniejących usług nie wymaga zmian w kodzie ani konfiguracji. Wystarczy uruchomić agenta OneAgent, by móc wykorzystać wszystkie dane w następujących przypadkach. Poza usługą pobierania danych przez agenta OneAgent przeprowadzamy też proces zbierania danych bez udziału takich narzędzi polegający na uzyskiwaniu dostępu do interfejsu API z poziomu punktów końcowych takich jak VMWare vCenter, F5 Load Balancers, Data Power, WMI czy JMX, co daje pełen obraz Twojego bieżącego środowiska.

5 kroków do lepszej migracji projektu

Moja prezentacja zawiera wiele przykładów, ale mam wrażenie, że poniższe 5 kroków to podstawowy zestaw, z którym powinien zapoznać się każdy. Poruszają one zasadnicze tematy:

  • Analiza technologiczna i zależności
  • Zużycie zasobów i analiza ruchu sieciowego
  • Bazy danych i migracja funkcjonalna

Krok 1. Poznaj technologię i dostępne usługi

„Co masz w ofercie?”

Na to pozornie proste pytanie wiele osób odpowiada zupełnie niepoprawnie, jak się okazuje po porównaniu ich wypowiedzi z faktami. Przed rozpoczęciem migracji, należy zbadać możliwości hostów, charakterystykę procesów, zakres usług i dostępne technologie. Dynatrace zawiera kilka ekranów, które dają mi dostęp do tych danych. Mogę też skorzystać z interfejsu Dynatrace API. Dla wielu osób to prawdziwe zaskoczenie, dlatego właśnie pokazuję tu ten zrzut z ekranu. To tak zwany przegląd dostępnych technologii, Technology Overview – siatka, która zapełnia się automatycznie wynikami w pełni automatycznego procesu detekcji, prowadzonego przez agenta Dynatrace OneAgent:

Dynatrace automatycznie wykrywa stosowane technologie, określa, gdzie są one uruchamiane i jakie oferują usługi. To dane zbierane W CZASIE RZECZYWISTYM poprzez zapytania wysyłane przez interfejs API.

Ten ekran to doskonałe miejsce, by rozpocząć poszukiwania odpowiedzi na kilka kluczowych dla procesu migracji pytań:

  • Z jakich technologii korzystamy w naszej organizacji? Gdzie się je uruchamia?
  • Które technologie są kandydatami do przeniesienia?
  • Które technologie są już przestarzałe i nie mogą być przeniesione, ponieważ nie są dłużej obsługiwane?
  • Dla których technologii mamy alternatywną ofertę?
  • Kto jest odpowiedzialny za każdą grupę technologii z uwzględnionych w rozważaniach?

Jeśli umiesz udzielić odpowiedzi na te pytania, to doskonale. Jeśli nie, rozpocznij okres próbny Dynatrace i zainstaluj agenta OneAgent.

Krok 2. Zrozumieć zależności — nie pozostawiaj hostów i procesów samym sobie

Większość naszych partnerskich chmur i platform korzysta z własnych narzędzi analizy zależności, przy czym zazwyczaj narzędzia te skupiają się na wykrywaniu podstawowych zależności w oparciu o analizę połączeń sieciowych między hostami. To dobry punkt początkowy, ale zapewnia dane, dzięki którym można przeprowadzić zaledwie klasyczną migrację w stylu „weź i przenieś” (Lift & Shift). Migracja tego typu ogranicza się zasadniczo do przeniesienia fizycznych lub wirtualnych hostów do chmury — po prostu sprowadza się ona do uruchomienia własnego hosta na cudzym sprzęcie. A do tego wystarczy znać zależności łączące poszczególne hosty.

Doświadczenia wyniesione ze współpracy z klientami, którzy modernizują swoje aplikacje, nauczyły mnie jednak, że klasyczne migracje w stylu „weź i przenieś” zdarzają się naprawdę rzadko. Zazwyczaj mamy do czynienia z połączeniem działań związanych ze zmianą architektury, zmianą platformy, przeprowadzeniem nowych zakupów oraz w przypadkach, w których ma to sens, z przeniesieniem hosta (Lift & Shift). Jeśli chcesz dowiedzieć się więcej na temat strategii migrowania, zapraszam do wpisu na moim blogu 6-R Migration Strategies (Strategie migrowania 6-R).

Aby wprowadzić w życie strategie modernizacyjne, należy zastosować bardziej drobiazgowe podejście do analizy zależności, ponieważ trzeba znaleźć odpowiedzi na bardziej szczegółowe pytania:

  • Jakie faktycznie mamy usługi?
  • Które z nich da się migrować samodzielnie, a które są powiązane ścisłymi zależnościami?
  • Jakie natężenie ruchu będzie zachodzić między przenoszonymi usługami oraz tymi, które pozostaną w dotychczasowym centrum danych?
  • Jakie wzorce użytkowania oraz wykorzystania zasobów są obecne w przypadku usług oraz ile będzie kosztować uruchamianie ich w chmurze?

Agent Dynatrace OneAgent pozwala znaleźć odpowiedzi na wszystkie te pytania, a ponadto wykrywa automatycznie wszystkie usługi, łączące je zależności i określa zużycie zasobów. Dane te są dostępne zarówno z poziomu interfejsu użytkownika Dynatrace, jak i przez Dynatrace Smartscape oraz interfejs Timeseries API:

Dynatrace Smartscape zawiera odpowiedzi na wszystkie pytania dotyczące zależności, jakie mogą pojawić się przy okazji migracji do chmury. Dane te są także dostępne przez interfejs Smartscape API.

Jakie natężenie ruchu panuje między dwoma procesami hostującymi określoną usługę? Na to pytanie odpowie Dynatrace — czy to z poziomu interfejsu użytkownika, czy za pośrednictwem interfejsu API.

Wszystkie te funkcje są dostępne dla hostów, na których zainstalowano agenta OneAgent. Ale skąd masz wiedzieć, że wszystkie hosty zostały sprawdzone? Czy wiesz w ogóle, które hosty są faktycznie częścią środowiska, do którego chcesz migrować? Dynatrace udzieli odpowiedzi także na to pytanie, ponieważ aplikacja pokazuje znane jej hosty, które niekoniecznie muszą być monitorowane w danej chwili:

Dynatrace automatycznie wskazuje hosty, usługi i domeny zewnętrzne, które nie są monitorowane w danej chwili

Pamiętaj: to jeden z krytycznych aspektów migracji. Nie chcesz przecież przenieść swojej usługi do chmury, by nagle odkryć znaczne opóźnienia w jej działaniu lub wzrost kosztów w wyniku nieuwzględnienia zapomnianej zależności.

Krok 3. Szczegółowa analiza zależności natężenia ruchu

Jeśli chcesz przenieść wybrane hosty bezpośrednio do chmury, musisz wiedzieć, jak korzystają one z łączącej je sieci oraz jak korzystają z sieci w przypadku połączeń z hostami, które nie będą przenoszone. Znajomość tych danych pozwoli Ci lepiej oszacować przyszłe koszty (ponieważ ruch przychodzący i wychodzący podlega opłatom), ale też pozwoli podjąć bardziej trafne decyzje w następujących sprawach:

  • W których miejscach ogólnie ograniczać transfer?
  • Których hostów nie należy przenosić, gdyż będą generować zbyt duży ruch?
  • W których miejscach zainwestować w kompresję danych?

Poniżej znajduje się jeden ze slajdów, na których wyjaśniam, jak uzyskać odpowiedź na pytanie: Co stanie się, jeśli przeniosę tę grupę serwerów?

W tym celu wystarczy oznaczyć host przeznaczone do migracji znacznikiem Dynatrace, a następnie wyodrębnić dane dotyczące użycia sieci dla tych hostów na hostach, które nie zostały oznaczone. Dynatrace pozwala definiować znaczniki ręczne i automatyczne, przy czym automatyczne można tworzyć na podstawie istniejących metadanych, na przykład części nazwy hosta, czy danych środowiskowych, na przykład: grup hostów VMWare. Ekstrakcję danych można też w pełni zautomatyzować, wykorzystując w tym celu Dynatrace Smartscape oraz interfejsu Timeseries API:

Dynatrace odpowiada na pytania dotyczące natężenia ruchu między grupami hostów, procesami lub usługami

Dane te, bieżące oraz historyczne, są także dostępne na poziomie procesu, co pokazuje poniższy zrzut z ekranu.

Dynatrace informuje o szczytowym natężeniu ruchu, wykorzystaniu zasobów procesora i pamięci dla każdego hosta, procesu i usługi

Krok 4. Inteligentne przenoszenie bazy danych

Przenoszenie bazy danych to temat, któremu można poświęcić osobny wpis na blogu, ponieważ Dynatrace daje odpowiedzi na naprawdę wiele pytań z tej dziedziny, dzięki czemu zapewnia udaną migrację danych. Zacznę od wymienienia kilku, które pojawiają się za każdym razem. Pokażę też klika zrzutów z ekranu, ilustrujących, jak za pomocą Dynatrace uzyskać odpowiedzi na poniższe pytania:

  • Jakie mamy bazy danych i które z nich kwalifikują się do przeniesienia?
  • Ile zasobów zużywają obecnie nasze serwery baz danych i jakie zasoby będziemy musieli zapewnić, jeśli zaplanujemy przeniesienie typu Lift & Shift?
  • Na które z aplikacji i usług zależnych od bazy danych wpłynie jej migracja? Które należy przenieść razem z bazą?
  • Jak prezentuje się obecna wydajność głównych zapytań w bazie danych oraz procedur składowanych? Które tabele i dane są kandydatami do przeniesienia do tańszego systemu bazy danych?

Które z baz danych należy przenieść?

Od chwili gdy zainstalujesz agenta OneAgent, Dynatrace automatycznie wykryje i zacznie monitorować wszystkie bazy danych, z których korzystają Twoje aplikacje i usługi. Dzięki tym danym łatwiej przyjdzie Ci zdecydować, które bazy danych są kandydatami do migracji, a które należy zastąpić innymi usługami bazodanowymi dostępnymi w chmurze:

Dynatrace daje informacje o wszystkich wykorzystywanych instancjach baz danych. Teraz możesz wybrać, które z nich nadają się do przeniesienia, które należy zachować, a które zastąpić!

Zmiana rozmiaru instancji bazy danych!

Przeniesienie w stylu Lift & Shift to doskonała okazja, by właściwie dobrać rozmiar instancji bazy danych. Dynatrace informuje o bieżącym zużyciu zasobów w czasie zwykłych godzin pracy, podczas szczytowego obciążenia oraz w okresach, gdy obciążenie jest niewielkie. Dzięki tym danym oszczędzisz koszty, nie tracąc przy tym wydajności pracy bazy danych oraz wybierając optymalny rozmiar instancji dla systemu docelowego:

Wykorzystaj dane Dynatrace, dotyczące wykorzystania zasobów przez bazę danych, do określenia właściwego rozmiaru przenoszonych instancji

Umieszczaj razem zależne usługi i aplikacje

Jeśli przenosisz bazę danych, zastanów się, które z mocno związanych z nią aplikacji i usług należy przenieść i umieścić razem z nią? Które z usług faktycznie korzystają z tych baz danych? Jakie rodzaje zapytań i procedur składowanych będą wykorzystywane?

Dzięki Dynatrace dowiesz się, które dokładnie zapytanie lub procedura składowana są wywoływane przez konkretne usługi lub aplikacje. Dowiesz się także, kiedy ma to miejsce. Dzięki temu zdołasz zredukować ryzyko migracji bazy danych, tabeli czy procedury składowanej w miejsce, w którym krytyczna dla systemu usługa (która powinna znaleźć się w ich pobliżu) będzie od nich znacznie oddalona:

Zrozumienie zależności łączących bazę danych z usługami niesie informacje o tym, które z usług należy przenieść razem z bazą, a które można pozostawić

Optymalizacja wydajności zapytań i koszt przechowywania danych

Jeśli masz dużą relacyjną bazę danych, której utrzymanie jest bardzo kosztowne (sprzęt i licencje), a planujesz przenosiny typu Lift & Shift, rozważ dwie następujące opcje.

  • Optymalizacja wydajności głównych zapytań
  • Wyprowadzenie mniej istotnych danych do tańszej w utrzymaniu bazy danych

Dynatrace pozwala uzyskać informacje dotyczące wykonania zapytań przez poszczególne aplikacje, ich wydajności oraz wpływu na ogólną wydajność wszystkich transakcji użytkownika. Dzięki tym danym możesz podczas migracji bazy do chmury zoptymalizować te zapytania, które mają kluczowe znaczenie dla prowadzonej działalności. Możesz też przeprowadzić migrację niektórych danych dotyczących mniej istotnych transakcji – na przykład raportów tylko do odczytu – do tańszej w utrzymaniu przestrzeni, dzięki czemu obniżysz koszty działania, bo przypuszczalnie zdołasz zmniejszyć liczbę licencji RDBMS.

Dane dotyczące wydajności zapytań, oferowane przez Dynatrace, pozwalają optymalizować najistotniejsze zapytania oraz rozważać przeniesienie mniej ważnych danych do tańszych w utrzymaniu magazynów danych!

Krok 5. Migracja funkcji a migracja zasobów

Gdy rozważamy migrację lub modernizację aplikacji, najczęściej mamy na myśli przeniesienie całej aplikacji lub usługi. Istnieje jednak podejście alternatywne, które określiłbym mianem migracji funkcji.

Zakłada ona przeniesienie wyłącznie tych funkcji, których migracja przyniesie zysk przedsiębiorstwu. Dam dwa przykłady:

  • Załóżmy, że z funkcji generującej największe przychody korzystają użytkownicy znajdujący się w znacznej odległości od centrum danych. W takim przypadku możesz chcieć przenieść tę usługę w taki obszar chmury, który będzie bliższy użytkownikom i tym samym podnieść ich komfort korzystania z usługi.
  • Jeśli oferujesz funkcję, która bazuje na dedykowanym sprzęcie, a użytkownicy korzystają z niej tylko raz w tygodniu (np. w przypadku raportów tygodniowych), tracisz mnóstwo zasobów przez cały czas, gdy funkcja ta nie jest używana. Przeniesienie jej do skalowalnej infrastruktury chmurowej z dostępem na żądanie zmniejszy koszty utrzymania tej funkcji, a nie wpłynie na komfort pracy użytkownika.

Dynatrace, poprzez rzeczywiste monitorowanie użytkowników, udostępnia informacje dotyczące usług uruchamianych po stronie serwera oraz usług interfejsu API uruchamianych po stronie użytkownika, a także funkcji przeznaczonych wyłącznie dla użytkownika. Dzięki temu zyskujesz lepszy wgląd w sezonowe zmiany danych, dotyczących korzystania z danej funkcji lub interfejsu API, a także sposób określenia, czy w systemie nie powstał żaden geograficzny punkt zapalny związany ze zużyciem zasobów obliczeniowych. Na podstawie tych danych można zadecydować, czy migracja pojedynczych funkcji nie byłaby lepszym rozwiązaniem niż migracja wszystkich aplikacji, hostów oraz centrów danych:

Dynatrace zapewnia informacje dotyczące zużycia zasobów dla poszczególnych funkcji, usług oraz punktów końcowych interfejsu API, które można wykorzystać podczas podejmowania decyzji dotyczących migracji funkcji

Tajny składnik nr 1 — Interfejs Dynatrace API

Wspomniałem wcześniej, że agent OneAgent jest tajnym składnikiem nr 1 w kwestii przechwytywania danych. Natomiast w przypadku wydajnego i automatycznego wykorzystania tych danych, w celu szybszego zaplanowania migracji, rola ta przypada interfejsowi Dynatrace API, który szybko przekaże zebrane dane do narzędzi migracyjnych.

W witrynie internetowej Dynatrace można znaleźć bogatą dokumentację, a w repozytorium GitHub umieściliśmy przydatne przykłady: https://github.com/Dynatrace/dynatrace-api. Wśród nich znajdziesz rozwiązania pozwalające pobierać dane Smartscape i Timeseries do arkusza Excel oraz generować własny wykres wizualizacji zależności na podstawie danych z interfejsu Smartscape API.

Polecam też własny niewielki projekt, który pokazuje możliwości interfejsu Dynatrace API — to Dynatrace CLI, czyli rozwiązanie pozwalające w wygodny sposób wysyłać zapytania dotyczące zależności oraz danych znaczników czasu: https://github.com/Dynatrace/dynatrace-cli

Zacznij już teraz i migruj z Dynatrace

Mam nadzieję, że udało mi się tu umieścić wszystkie odpowiedzi na pytania, które sformułowałem na początku:
W jaki sposób Dynatrace może pomóc zmniejszyć ryzyko takiego przejścia, przyspieszyć je i pomóc w generowaniu zysków w związku ze zmianą platformy na chmurę?

Najlepszym punktem startu będzie rozpoczęcie okresu próbnego z Dynatrace lub skontaktowanie się z zespołem Dynatrace, jeśli już jesteś naszym klientem. Zainstaluj agenta OneAgent i bierz się do pracy. W razie pytań skontaktuj się z nami — nasi eksperci pomogą Ci przygotować projekt migracji.

 

 · 5 sierpnia, 2019