Migracja w ostateczności

Problemy z wydajnością i pojemnością systemów do składowania danych nie zawsze oznaczają obiektywny przymus migracji danych. Jeśli jednak nie ma innego wyjścia, proces migracji można przeprowadzić na wiele sposobów.

Problemy z wydajnością i pojemnością systemów do składowania danych nie zawsze oznaczają obiektywny przymus migracji danych. Jeśli jednak nie ma innego wyjścia, proces migracji można przeprowadzić na wiele sposobów.

Migracja danych zawsze jest przedsięwzięciem poważnym i obarczonym ryzykiem - tym trudniejszym, im więcej danych trzeba przenieść, choć oczywiście nie jest to jedyne kryterium. Równie ważna jest struktura typów danych, liczba korzystających z nich aplikacji, a także stopień skomplikowania procesów biznesowych opartych na danych elektronicznych.

W kontekście migracji pojawia się ponadto wiele zagadnień dodatkowych, których początkowo nie rozważa się jako będących w zakresie projektu migracyjnego. Opracowanie koncepcji rozdziału biznesowej przynależności danych, koncepcji operacyjnego zarządzania nimi, jak również długofalowej strategii ich zabezpieczania - te kwestie wymagają rozwiązania właśnie na etapie migracji, choć nie od razu jest to oczywiste.

Wszystkie te czynniki skłaniają do wniosku, że zanim cokolwiek zostanie zamówione, a nawet zanim stworzona zostanie lista potencjalnych rozwiązań, wypada poświęcić czas na planowanie i uzgodnienia. W trakcie tego procesu może się okazać, że rzeczywiste potrzeby są inne niż początkowo się wydawało. Ostateczny pomysł na rozwiązanie może okazać się bardzo różny od początkowego.

Trzeba ustalić fakty

Nie można mówić o migracji danych bez wskazania przyczyn, dla których dotychczasowe rozwiązanie nie spełnia oczekiwań. Może ich być całkiem sporo i mogą przy tym występować rozdzielnie bądź łącznie. Jednym z najczęściej wymienianych powodów jest ograniczona pojemność istniejącego rozwiązania, a zaraz po nim wydajność aplikacji. Strategia migracji w obu tych przypadkach powinna powstać po upewnieniu się co do rzeczywistych powodów istniejącego stanu rzeczy.

Argumenty o niewystarczającej pojemności pojawiają się bardzo często w sytuacji, gdy firma nie panuje nad tym, jakie dane rzeczywiście posiada w systemach przeznaczonych do ich składowania. Jeśli do tej samej macierzy podłączone są serwery z bazami danych i serwery plików, brak możliwości rozszerzenia pojemności bazy danych będzie wynikać w znakomitej większości przypadków z braku kontroli nad wzrostem ilości danych na serwerach plików.

Nie jest to jednak dobry powód do zakupu kolejnej macierzy. Taniej i prościej można zbadać zawartość serwera plików i usunąć z niego to, o czym wszyscy administratorzy wiedzą, lecz wstydzą się powiedzieć otwarcie: filmów i muzyki przechowywanej przez użytkowników. Oczywiście, niezgodnie z zasadami, co jednak nie jest tu istotne. Ważne jest to, że migracja w wielu przypadkach w ogóle nie jest konieczna - wystarczy zrobić porządek w systemie plików.

Również problemy z wydajnością nie zawsze leżą tam, gdzie można by się ich spodziewać. Niewystarczająca wydajność serwera baz danych obsługującego kluczowe aplikacje może wywołać potrzebę pilnego działania, ale niekoniecznie musi to być zakup nowej macierzy i migracja danych. Zanim to nastąpi, wypadałoby sprawdzić, jak stare są dane przetwarzane w bazie.

Często zapytania SQL przechodzą przez wielkie tabele, z których większość to dane historyczne, całkowicie nieużyteczne w codziennej pracy. Warto by także przyjrzeć się kluczowym indeksom i zbadać, czy nie trzeba stworzyć nowych, lepiej oddających aktualną charakterystykę pracy bazy danych, która przecież ulega zmianom. Dopiero gdy te wstępne czynniki zostaną zweryfikowane, można rzeczywiście mówić o potrzebie migracji danych na nowszy - szybszy i/lub pojemniejszy sprzęt.

Co problem, to metoda

Migracja danych ma sens wtedy, gdy dobrze rozumie się zasady i perspektywy skalowania posiadanych aplikacji. To oczywiste, ale nie zawsze posiadana wiedza zostaje właściwie wykorzystana. Jeśli problem polega na tym, że system gromadzi coraz więcej danych przy niewiele zmieniającej się liczbie użytkowników, celem migracji powinna być poprawa wydajności kontrolera macierzowego, wykorzystanie wydajniejszych dysków i szybszej sieci do komunikacji między serwerem i macierzą.

W przypadku rosnącej liczby użytkowników i związanym z tym wzrostem liczby transakcji, zmiany po stronie infrastruktury dyskowej nie zawsze istotnie podnoszą wydajność. Przyczyna problemów z wydajnością w takich przypadkach zazwyczaj (choć nie zawsze) jest po stronie serwera. Być może serwer baz danych potrzebuje więcej pamięci RAM, by nie było przymusu częstego zapisywania danych na dyski. Nawet najszybsze dyski nie zastąpią pamięci RAM, a w pewnym stopniu również lepszego dostrojenia systemu.

Być może zastosowana strategia ochrony danych nie jest dostosowana do jego wydajności? Kopie migawkowe wykonywane na poziomie serwera, a nie macierzy (nie wspominając już o tradycyjnym backupie w trybie online), mogą go istotnie obciążać. Zanim dojdzie do migracji, trzeba jeszcze ustalić, czy jej powodem nie jest rosnąca objętość danych podstawowych lub też liczba ich kopii wykonywana na różne potrzeby (kopia "gorąca" na potrzeby szybkiego odtwarzania, kopia na potrzeby aplikacji analitycznych, kopia na potrzeby archiwizacyjne itd.).

Dla strategii migracji znaczenie ma ilość danych do przeniesienia oraz ich aktualna struktura. Nie chodzi o wielkości absolutne, lecz o to, ile czasu potrzeba na przeniesienie danych z jednej macierzy do drugiej i przetestowanie skopiowanych danych. W tym kontekście istotne jest, czy przeniesienie danych można podzielić na etapy, by nie czynić z tego ogromnego przedsięwzięcia, które niepotrzebnie podnosiłoby koszty i ryzyko całej operacji.

Najlepiej, gdyby za jednym razem udało się przenieść i przetestować dane jednej aplikacji, co jednak w obecnych warunkach nie zawsze jest proste. Po pierwsze dlatego, że wiele firm pracuje w trybie 24/7, a po drugie, że jeden logiczny serwer baz danych zarządza wieloma bazami wykorzystywanymi przez wiele aplikacji. Taka baza, zawierająca np. dane przestrzenne, potrafi mieć objętość rzędu terabajtów i konia z rzędem temu, kto przeniesie i przetestuje taką porcję danych w jeden weekend.

Kopia na wiele sposobów

Oddzielnym zagadnieniem jest strategia przenoszenia danych, która jest pochodną skomplikowania środowiska aplikacyjnego. Jeśli wiele aplikacji korzysta z tego samego serwera baz danych w trybie 24/7, przeniesienie danych z konieczności musi się odbyć etapami. Można wykonać pełny backup bazy podstawowej i skopiować ją do nowej macierzy w trybie offline, a później dodać do nich w trybie transakcyjnym dane różnicowe. Ta strategia wydaje się dobra zwłaszcza wtedy, gdy migracja danych jest spowodowana budową odległego zapasowego centrum danych.

Jeśli dane mają zostać skopiowane lokalnie, cały proces można próbować rozłożyć w czasie, kopiując dane w trybie replikacyjnym między stojącymi obok siebie macierzami. Ten scenariusz będzie jednak możliwy tylko wtedy, gdy serwer baz danych ma dostateczny zapas mocy, by obsłużyć taki proces (to argument za tym, by w trakcie wymiany infrastruktury najpierw wymieniać serwer, a później migrować dane). Jeśli istnieje taka możliwość, replikację najlepiej jest wykonać na poziomie macierzy. Problem w tym, że nie wszystkie macierze oferują taką funkcjonalność, a jeśli już, jest to funkcjonalność dosyć kosztowna.

W tym wypadku można posłużyć się macierzami lub kontrolerami wirtualnymi (nawet w postaci czysto programowej). Na nowej macierzy/kontrolerze należy wówczas zdefiniować idealną kopię dotychczasowej mapy wolumenów i katalogów, a następnie skojarzyć ją jednocześnie z nową i starą macierzą. W ten sposób aplikacje będą zapisywać dane do znanych im, dotychczasowych ścieżek logicznych, "nie wiedząc" o tym, że w tle, poza ich kontrolą, dane są nieśpiesznie kopiowane ze starej macierzy do nowej aż do momentu uzyskania pełnej spójności. Odłączenie starej macierzy nie zostanie wtedy nawet zauważone.

Migracja danych może odbywać się także z wykorzystaniem mechanizmów kopii migawkowych. W sumie chodzi o skopiowanie spójnego obrazu danych między dwoma zestawami urządzeń do ich składowania. Oczywiście, kopia migawkowa jest jedynie kopią wskaźników, a nie samych danych, ale współczesne mechanizmy pozwalają na zbudowanie na równolegle działającym urządzeniu kopii wolumenu na poziomie sektorowym, a następnie wypełnienie jej danymi w trybie asynchronicznym. To może być najłatwiejszy ze sposobów wykonania całej operacji, zarówno lokalnie, jak i zdalnie.

Po pierwsze: nie utrudniać

Wśród przyczyn migracji nie wspomniano wyżej o innych powodach, które mogą się pojawić w praktyce. Może nim być brak możliwości uzyskania sensownej ceny za wsparcie techniczne starzejącej się macierzy, albo nieusuwalna niekompatybilność między nową aplikacją, a sterownikiem macierzowym lub jakakolwiek inna nietypowa przyczyna. Za każdym razem trzeba jednak nabrać pewności, że właśnie to, a nie co innego stanowi źródło problemu. Szybkie decyzje o migracji nie sprzyjają stabilności działania firmy i jej bezpieczeństwu.

Nie oznacza to oczywiście, że należy zawsze kupować systemy możliwie największe i najbardziej skalowalne, by migrację danych odsunąć w czasie. Warto raczej przyjąć myślenie, że migracja prędzej czy później będzie koniecznością i dbać o to, by nie podejmowano działań, które mogą w przyszłości ją utrudnić.

W celu komercyjnej reprodukcji treści Computerworld należy zakupić licencję. Skontaktuj się z naszym partnerem, YGS Group, pod adresem [email protected]

TOP 200