Przenosimy nasze serwery do chmury. Dlaczego warto?

Firmy, które migrują aplikacje i programy IT do chmury, często doświadczają zwiększonej produktywności, niższych kosztów ogólnych i mniejszej liczby problemów związanych z IT. Firmy, które opóźniają migrację do chmury, często tracą swoją przewagę konkurencyjną na rynku. Chmura składa się z niezliczonych serwerów i centrów przechowywania danych – podobnych do tych, z których firmy od lat korzystają wewnętrznie. Różnica polega na tym, że serwery w chmurze znajdują się poza siedzibą firmy, a dostęp do nich możliwy jest za pośrednictwem mocno zaszyfrowanych, szybkich połączeń danych.

Serwery w chmurze umożliwiają automatyczne aktualizacje i uaktualnienia oprogramowania w czasie rzeczywistym. Innymi słowy, koniec z zajmowaniem się powolnymi, przestarzałymi, niestabilnymi i przeciążonymi systemami. Chmura wiąże się również z łatwiejszą obsługą. Takie serwery eliminują obciążenie i kłopoty związane z ich fizyczną obecnością, a także obsługą pakietów do ich oprogramowania. Eliminują również koszty zatrudnienia stałego zespołu ekspertów komputerowych do ich obsługi na miejscu.

Niezawodność naszych systemów komputerowych cechują takie parametry jak: RPO, RTO oraz SLA. Czym one są?

SLA – Service Level Agreement, określa poziom usług, jakiego oczekujesz od dostawcy, określając metryki, według których mierzona jest usługa, a także zawiera środki zaradcze lub kary, jeśli uzgodnione poziomy usług nie zostaną osiągnięte. Jest to krytyczny element każdej umowy z dostawcą technologii.

SLA stanowi kluczowy element każdej umowy z dostawcą usług outsourcingowych i technologicznych. Poza wyszczególnieniem oczekiwań dotyczących typu i jakości usługi, umowa SLA zapewnia środki zaradcze, gdy wymagania nie są spełnione.

Dlaczego potrzebuję umowy SLA?

SLA jest integralną częścią umowy z dostawcą IT. Gromadzi ona w jednym dokumencie informacje o wszystkich zakontraktowanych usługach i ich uzgodnionej oczekiwanej niezawodności. Jasno określa wskaźniki, obowiązki i oczekiwania, aby w przypadku problemów z usługą każda ze stron posiadała takie samo zrozumienie względem wymagań.

Każdy znaczący kontrakt bez powiązanej umowy SLA (sprawdzonej przez radcę prawnego) może być celowo lub nieumyślnie błędnie zinterpretowany. Umowa SLA chroni obie strony kontraktu. Idealnie byłoby, gdyby SLA było dostosowane do technologii lub celów biznesowych. Niewspółosiowość może negatywnie wpływać na ceny transakcji, jakość świadczenia usług i obsługę klienta.

Strategia na SLA

Planując strategię ochrony danych lub odzyskiwania ich po awarii, należy wziąć pod uwagę kilka kryteriów, by móc dostosować się do tego, jaki wpływ posiadają różne aplikacje i jakie obciążenie mają one na działalność. Analiza wpływu na biznes może pomóc w ocenie i rozważeniu konsekwencji, zarówno finansowych, jak i niefinansowych, jakie wiążą się z przerwą w działalności biznesowej. Te ustalenia mogą pomóc organizacjom w określeniu ich umów dotyczących poziomu usług (SLA) lub dostępności oczekiwanych przez klienta od jednostki świadczącej usługę. Najczęściej wiele umów SLA definiuje się w zależności od różnych poziomów krytyczności, które zostały określone podczas wspomnianej analizy.

Najczęściej używanymi umowami SLA są:

• 99%, czyli „dwa razy 9” – odpowiadająca 3 dniom 15 godzin i 36 minutom przestoju w roku,
• 99,9%, czyli „trzy razy 9”, odpowiadająca 8 godzinom 45 minutom i 36 sekundom przestoju w roku,
• 99,99%, czyli „cztery razy 9”, odpowiadająca 52 minutom i 34 sekundom przestoju w roku.

Umowy SLA dotyczące dostępności są tłumaczone przez dział IT lub dostawcę usług na przystępną cenowo utratę danych i nieplanowane przestoje. Recovery Point Objective (RPO) i Recovery Time Objective (RTO) to dwie najważniejsze konstrukcje umowy SLA i reprezentują te cele.

Najważniejsze parametry przy planowaniu SLA

Na pierwszy rzut oka te dwa terminy wydają się być dość podobne. Najlepszym sposobem na zrozumienie różnicy między nimi jest skojarzenie „RP” w „RPO” poprzez wyobrażenie sobie, że oznaczają one „Rewrite Parameters” i „RT” w „RTO” jako „Real-Time”.

Co oznacza RPO w ochronie danych w chmurze?

Cel punktu odzyskiwania (RPO) opisuje przedział czasu, który może upłynąć podczas zakłócenia, zanim ilość danych utraconych w tym okresie przekroczy maksymalny dopuszczalny próg lub „tolerancję” planu ciągłości działania.

Przykład: Jeśli ostatnia dostępna dobra kopia danych po awarii pochodzi sprzed 18 godzin, a RPO dla tej firmy wynosi 20 godzin, nadal mieści się w parametrach RPO Planu Ciągłości Działania. Innymi słowy, odpowiada na pytanie „Do którego momentu odzyskiwanie procesu biznesowego może przebiegać znośnie, biorąc pod uwagę ilość danych utraconych w tym przedziale?”.

Co oznacza RTO w rozwiązaniach związanych z odzyskiwaniem danych po awarii?

Cel czasu odzyskiwania (RTO) to poziom usług i czas trwania, w którym proces biznesowy musi zostać przywrócony po awarii, aby uniknąć niedopuszczalnych konsekwencji związanych z przerwą w ciągłości. Innymi słowy, RTO jest odpowiedzią na pytanie „Ile czasu zajęło odzyskanie sprawności po otrzymaniu powiadomienia o zakłóceniu procesu biznesowego?”.

RPO oznacza zmienną ilość danych, które zostaną utracone lub będą musiały zostać ponownie wprowadzone podczas przestoju sieci. RTO oznacza ilość „czasu rzeczywistego”, która może upłynąć, zanim zakłócenie zacznie poważnie i niedopuszczalnie utrudniać przepływ normalnych operacji biznesowych.

Jak obliczać RPO?

Istnieje wiele czynników, które wpływają na RPO firmy i różnią się w zależności od aplikacji. Poniżej znajdują się niektóre czynniki, które mogą wpływać na RPO:

• maksymalna dopuszczalna utrata danych dla konkretnej organizacji,
• czynniki specyficzne dla branży – firmy zajmujące się poufnymi informacjami, takimi jak transakcje finansowe lub dokumentacja medyczna, muszą być częściej aktualizowane,
• opcje przechowywania danych, takie jak pliki fizyczne w porównaniu z przechowywaniem w chmurze, mogą wpływać na szybkość odzyskiwania,
• koszt utraty danych i utraconych operacji,
• koszt wdrożenia rozwiązań do odzyskiwania po awarii.

Należy pamiętać, że zawsze istnieje luka między wartościami rzeczywistymi (Recovery Time Actual (RTA) i Recovery Point Actual (RPA)) a celami wprowadzonymi przez różne ręczne i zautomatyzowane kroki w celu uruchomienia aplikacji biznesowej. Te fakty mogą być ujawnione tylko poprzez testowe próby wywołania katastrof i zakłóceń biznesowych.

Jak wyglądają typowe kopie zapasowe?

Tradycyjne kopie zapasowe
Obrazując to na przykładzie, w tradycyjnych kopiach zapasowych na taśmach tworzenie kopii trwa 2 godziny dla kopii zapasowych zaplanowanych o godzinach 06:00 i 18:00, awaria głównej lokalizacji o godzinie 14:00 pozostawi opcję przywrócenia kopii zapasowej z godziny 06:00, co oznacza RPA 8 godzin i 2 godziny RTA.

Ciągła replikacja
Replikacja zapewnia wyższe gwarancje RPO, ponieważ system docelowy zawiera lustrzany obraz źródła. Przykładowo, dopiero w momencie, gdy replikujemy dane w dwóch miejscach, to oba z nich muszą ulec awarii, aby doszło do utraty danych, tak więc minimalizuje to ryzyko utraty danych.

Serwery Amodit w chmurze

Właśnie dlatego przenosimy nasze serwery do chmury jednego z czołowych dostawców usług na świecie. Wszystkie dane są przechowywane na replikowanych serwerach baz danych, dostęp do aplikacji obsługują zdublowane serwery WWW, pobierające dane z rozproszonych i dublowanych dysków z danymi. Oznacza to ciągłość funkcjonowania biznesu.

Od strony oprogramowania, w chmurze funkcjonuje najnowsza wersja Aplikacji Amodit, dostosowywana od dawna do wymogów chmury.

Regularnie wykonujemy kopie zapasowe baz danych i serwerów plików. Wszystko to pomaga w dużym stopniu zmniejszyć wartość parametrów RPO i RTO, a co za tym idzie podnieść poziom SLA oferowanych przez Astrafox usług oraz jeszcze bardziej zwiększyć bezpieczeństwo danych naszych klientów.

Przekonaj się, jak Amodit może pomóc Twojej firmie