Lista dostawców Disaster Recovery

Lista dostawców Disaster Recovery

Ekosystem usługodawców i znawców odtwarzania awaryjnego operujących w Polsce to ciągle jeszcze mała enklawa. Firm i osób znających ten obszar jest mało. Jeszcze mniej jest tych, dla których DRaaS, czy DRC stanowią ważną linię biznesu. Lista będzie aktualizowana, więc warto zaglądać.

Od pierwszej wersji Listy dostawców DRaaS minął ponad rok. Wówczas zestawienie powstało przy okazji projektu. Właściwie to mój klient miał wpływ na większość kryteriów wyboru (zainteresowanych odsyłam do pierwotnego artykułu). Tym razem zaprosiłem do udziału zarówno usługodawców dysponujących Odtwarzaniem awaryjnym w postaci usługi (Disaster Recovery as a Service) jak i klasycznych dostawców Centrów Awaryjnych (Disaster Recovery Center/Site). Nie zamykam listy usługodawcom mających centra danych poza obszarem RP. Najważniejsze by podmioty działały w Polsce i podlegały polskiej legislacji. Z każdym zatem możecie śmiało rozmawiać w naszym języku. Żeby było łatwiej dotrzeć do właściwych osób, podaję Wam nazwiska, rozumiecie – RODO. Dane teleadresowe znajdziecie na stronach dostawców.

Zestawienia tym razem w postaci tabelarycznej, by można było łatwo poddać je własnej edycji. Każdą tabelkę możecie skopiować lub pobrać w kilku formatach. Na początku prezentuję usługodawców DRaaS, a następnie firmy oferujące DRC/VDRC/DRS (więcej o terminologii znajdziecie w tym artykule). Nadmienię, że niektórzy dostawcy DRaaS także realizują usługi projektowe.

Dostawcy DRaaS

Czyli Odtwarzanie awaryjne w postaci usługi. Skrócona charakterystyka:

  • Natychmiastowa dostępność, bo to architektura wielu najemców, czyli środowisko jest i czeka na klientów.
  • Niski koszt usługi, gdyż zazwyczaj formuła SaaS, czyli współdzielenie zasobów powoduje korzyści skali.
  • Trochę ograniczeń wynikających z formy realizacji usługi, technologii i skalowalności.
  • Rozliczenie wyłącznie abonamentowe, a więc póki płacisz używasz.
3S Data Center any.cloud Engave Exea Data Center
Nazwa usługi 3S Cloud2B Disaster Recovery ReVirt DRaaS Doublecloud DRaaS
Strona o usłudze https://cutt.ly/Cloud2B https://cutt.ly/ReVirt https://cutt.ly/Engave https://cutt.ly/Exea
Lokalizacja centrum danych Katowice, Warszawa, Kraków Kopenhaga Warszawa (Netia) Toruń
SLA centrum danych 99.999% 99.999% 99.99% 99.99%
SLA usługi 99.50% 99.9% - 99.99%
ISO 27001 W certyfikacji Tak Tak Tak
ISO 22301 Nie Tak Nie Tak
Inne certyfikaty i standardy Veeam Platinum Service Provider, VMware Service Provider Program – Enterprise Level, VMware Solution Provider Program - Professional Level, Fujitsu SELECT Expert Partner ISO 27002, ISAE 3402, SOC2 - TIER III (facility & design)
Czas uruchomienia 4h 1 h 2 h 1 h
Darmowy okres próbny 14 dni 30 dni 14 dni 30 dni
Technologia Veeam Veeam Veeam Veeam
Obsługiwane hypervisory ESXi, Hyper-V ESXi, Hyper-V ESXi, Hyper-V ESXi
Obsługa maszyn fizycznych Tak Nie Nie Nie
Portal usługi Tak Tak Nie https://vac.exea.pl
Metoda rozliczenia Abonament miesięczny, w cenie testy przez 7 dni na m-c. Licencje OS/DB (o ile wymagane) za cały miesiąc. Ryczałt miesięczny za replikację. Uruchomienie awaryjne rozliczane za dzień. Ryczałt miesięczny za replikację. Uruchomienie awaryjne rozliczane za użycie. Ryczałt miesięczny za replikację. Uruchomienie awaryjne rozliczane za godziny (raz na pół roku). Licencje OS/DB (o ile wymagane) za cały miesiąc.
Wynajem licencji OS/DB Tak Nie Nie Tak
Minimalne RPO 15 min 5 min 15 min 15 min
Minimalne RTO 30 min 15 min 120 min 15 min
Konfiguracja środowiska klienta Tak Tak Tak Tak
Plan odtwarzania awaryjnego Tak Tak Tak Tak
Okres związania umową miesiąc 3 miesiące 6 miesięcy miesiąc
Cykl rozliczeniowy miesiąc miesiąc miesiąc miesiąc
Kontakt handlowy solutions@3s.pl Michał Drąg Tomasz Strugalski Marcin Zawadzki, Dawid Goljat

Dostawcy DRC / VDRC / DR Site

Najczęściej dla wymagających klientów. To klasyczne podejście, czyli projektowe, a więc na zamówienie przygotowanie środowiska odtwarzania awaryjnego. Składowe usługi to zwykle: kolokacja, najem sprzętu (opcja), konfiguracja (opcja) transmisji danych i serwis. Krótka charakterystyka usług w zakresie Disaster Recovery Center:

  • Uruchomienie usług zależne od wielkości projektu, zwykle zajmuje kilka lub nawet kilkanaście tygodni.
  • Wysoki koszt usług, który kształtuje amortyzacja sprzętu kupionego pod projekt.
  • Duża dowolność w sposobie realizacji usługi.
  • Rozliczenie zwykle mieszane – inwestycja i abonament.
3S Data Center Atman Exea Data Center DataCenter PPNT
Nazwa usługi DRC DRC DRaaS DC PPNT
Strona o usłudze https://cutt.ly/Priv_Cloud www.atman.pl https://exea.pl https://datacenterppnt.pl/pl
Lokalizacja centrum danych Katowice, Warszawa, Kraków Warszawa (Grochowska, Konstruktorska), Katowice Toruń Poznań
SLA centrum danych 99.999% 99.99% 99.99% 99.50%
ISO 27001 W certyfikacji Tak Tak Tak
ISO 22301 Nie Nie Tak Nie
Inne certyfikaty i standardy TIER III/3, ISO 9001, Świadectwo Bezpieczeństwa Przemysłowego I stopnia ISO 9001, DCOS TIER III (facility & design) ISO 20000-1, ISO 9001
Certyfikacje producentów Veeam Platinum Service Provider, VMware Service Provider Program – Enterprise Level, VMware Solution Provider Program - Professional Level, Fujitsu SELECT Expert Partner - VMware Enterprise Cloud Provider, Veeam Gold Pro Partner, Microsoft Silver Partner, VMCE Veeam Gold Cloud Provider, Microsoft Partner Datacenter Silver, Vmware Professional Service Provider Partner, MCSA
Model rozliczeniowy Opex, Capex Capex, Opex Opex Opex
Wynajem licencji OS/DB Tak Tak Tak Tak
Konfiguracja środowiska klienta Tak Tak Tak Tak
Plan odtwarzania awaryjnego Tak Tak Tak Tak
Okres związania umową 12 miesięcy brak 12 miesięcy brak
Cykl rozliczeniowy miesiąc miesiąc miesiąc miesiąc
Kontakt handlowy solutions@3s.pl drc.info@atman.pl Marcin Zawadzki, Dawid Goljat Dominik Bocheński

Osoby, które znają się na DR

Już wkrótce promocja specjalistów, handlowców, konsultantów i inżynierów – znawców tematu! Warto zaglądać.

Nadmiarowość, czy odtwarzanie po awarii?

Nadmiarowość, czy odtwarzanie po awarii?

Czym jest uptime i jak się to ma do czasu przestoju?  Ile dziewiątek po przecinku gwarantuje względny spokój, gdy mowa jest o wysokiej dostępności infrastruktury informatycznej? I na koniec, na co postawić: na nadmiarowość czy może na błyskawiczne odtwarzanie po awarii?

Czy wiesz jaki poziom dostępności mają Twoje systemy?  Najlepsze centra danych w Polsce (np.: Atman, Beyond, Exea, Polcom, T-mobile), mogą pochwalić się niezawodnością na poziomie 99,99%. Oznacza to, że ich przestój w skali roku nie przekroczy godziny. Zwracam jednak uwagę, że procenty dotyczą określonych usług. Już tłumaczę. Powiedzmy, że zdecydujemy się na usługę kolokacji, czyli wynajmujemy miejsce w szafach teletechnicznych w centrum danych. Usługodawca deklaruje cztery dziewiątki. Czy w związku z tym nasze środowisko także będzie miało dostępność na poziomie 99,99%? Najprawdopodobniej nie. Wysoka dostępność dotyczy systemów zbudowanych w centrum danych, w tym zasilania, łączności, klimatyzacji, itp. Wystarczy, że architektura naszego rozwiązania została zaprojektowana bez nadmiarowości. Czyli do szaf wynajętych w centrum danych włożymy pojedyncze urządzenia. Wówczas niestety, poziom dostępności naszego środowiska IT będzie równy poziomowi dostępności najsłabszego elementu.

Czas nieprzerwanej pracy systemów określany jako uptime, dotyczy każdego elementu infrastruktury IT. Projektując wysokodostępne środowisko IT należy eliminować pojedyncze punkty awarii. Robimy to dublując urządzenia z najniższym przeciętnym uptime. Właściwie, to robimy to dublując wszystko co się da 🙂 Jedyne odstępstwa dotyczą usług, których niedostępność nie zatrzymuje procesów krytycznych dla działalności operacyjnej. W ten sposób istotnie zmniejszamy ryzyko wystąpienia przestojów. Naturalnie, poszczególne systemy nie muszą mieć jednakowego poziomu dostępności. Ustalanie precyzyjnych wskaźników dla każdej usługi wpływa wprost na poziom nakładów na środowisko IT i na rodzaj i koszt Disaster recovery.

Wysoka dostępność (HA) jest pochodną nadmiarowości. Odtwarzanie awaryjne uznać powinniśmy za uzupełnienie HA, bo odpowiada na problemy, których nie rozwiąże nawet rozproszony geograficznie klaster wysokiej dostępności. Disaster recovery (np. DRaaS) to ostatnia deska ratunku, gdy nasze systemy padną ofiarą cyberataku lub co bardziej prawdopodobne, staną się niedostępne przez jakiegoś wirusa szyfrującego. Moje doświadczenia pokazują, że nadmiarowość i odtwarzanie po awarii, które według najlepszych praktyk ITIL powinny być komplementarne, bardzo często rozdziela tytułowe „czy”.

Czy małe i średnie firmy potrzebują Disaster recovery?

Czy małe i średnie firmy potrzebują Disaster recovery?

Znawcy tematu (celowo unikam słowa eksperci) twierdzą, że Ciągłość Działania i Disaster recovery są dla firm z ustabilizowanymi przychodami. Firmy te z natury rzeczy doskonalą procesy. Co Wy na to? No właśnie, jak zwykle to zależy. Czy mała firma udostępniająca swoje systemy transakcyjne klientom i kontrahentom przetrwa kryzys w postaci dwudniowego przestoju serwerów? Pewnie tak, ale statystycznie ma o wiele mniejsze szanse niż firma duża.

W Stanach Zjednoczonych Ameryki, powstała ku przestrodze i pewnie „na zachętę” 😉 pewna statystyka. Mówi się w niej, że aż 93% firm, których centra danych nie funkcjonowały 10 lub więcej dni, ogłosiły upadłość w ciągu roku. Na dokładkę, ponad 60% firm, które całkowicie utraciły dane, zamknięto w przeciągu sześciu miesięcy. Statystyka pochodzi z NARA, czyli National Archives and Records Administration, co w wolnym tłumaczeniu oznacza: Krajową Administrację Archiwów i Rejestrów. Danych źródłowych nie widziałem, ale domyślam się, że próba została dobrana rzetelnie przez wzgląd na rangę instytucji.

Jak to wygląda u nas? Polskich statystyk chyba jeszcze nikt nie zrobił (kto widział lub słyszał niech napisze, odwdzięczę się!). Tyle, że my Polacy jesteśmy bardzo zaradni i nie takie rzeczy przeżyliśmy 😉 A tak na poważnie. Odporność biznesu jest pochodną rodzaju biznesu i rozkładu przychodów. Jeśli na przykład nasze przychody mają liniowy charakter, wówczas nakłady na Ciągłość Działania są niezbędne. Jeśli działamy projektowo, wtedy mamy mniejszą wrażliwość na przerwy dostępności infrastruktury informatycznej i aplikacji.

Pamiętajmy przy tym wszystkim o tym jaką mamy „poduchę”. Chodzi o to, jakie mamy kapitały własne, aktywa szybko zbywalne, stan konta, itd. Zazwyczaj, małe firmy mają płynność opartą na rolowaniu należności. Wówczas, wszelkie zasoby gotówki są w obrocie lub są natychmiast reinwestowane, a limity kredytowe są bardzo małe lub nie ma ich wcale. W takiej sytuacji, przerwa napływu gotówki powoduje natychmiastowe problemy płatnicze. O tym, że jak krytyczna jest płynność finansowa przekonywać nie muszę. Jeśli do tego dołożyć: problemy wizerunkowe związane z przestojem, kary umowne, to niebezpiecznie zbliżamy się do scenariusza, który może położyć firmę. Dlatego, moim zdaniem Disaster recovery jako usługa (DRaaS) to pozycja obowiązkowa dla małego i średniego biznesu.

Czy kopia zapasowa (backup) to ratunek od przestoju?

Czy kopia zapasowa (backup) to ratunek od przestoju?

Po co nam usługi disaster-recovery, przecież my nie żyjemy w Ameryce. W końcu jakie jest prawdopodobieństwo katastrofalnego zdarzenia, które akurat zniszczy nasz budynek? Uwielbiam taką retorykę! A już Albert Einstein mówił: „Wyobraźnia jest ważniejsza od wiedzy, ponieważ wiedza jest ograniczona”. Proponuję zatem nieco poszerzyć nasze horyzonty i rozważyć, czy rzeczywiście w każdym przypadku dobrze wykonany backup to ratunek od przestoju.

Skojarzenie dotyczące katastrof najczęściej bierze się z rozdzielnego tłumaczenia wyrazów „disaster” i „recovery”. Wówczas krążymy wokół zdarzeń kategorii: tornado, upadek statku powietrznego, pożar czy powódź. Tymczasem już Google Translator to zestawienie wyrazów tłumaczy jako: „odzyskiwanie po awarii”. A że awaria me wiele imion i zwykle wydarzy się w najgorszym momencie, to i jest miejsce na rozważania czy ten firmowy backup to na pewno odpowiedź na każdą sytuację. Odpowiedź oczywiście jest przecząca.

Pora na konkrety. Kiedy zdecydowanie potrzebujesz usług disaster-recovery:

  1. Jeśli przetwarzasz dane we własnej serwerowni, która nie spełnia standardu Uptime Institute Tier II lub ANSI/TIA-942 Tier 2.
  2. Gdy nie dublujesz kluczowej infrastruktury (serwery, przełączniki) i nie stosujesz mechanizmów wysokiej dostępności (high availability).
  3. Gdy sprzęt, którego używasz ma więcej niż 3 lata i jest już po gwarancji.
  4. Jeśli Twój kontrakt serwisowy z dostawcą przewiduje naprawę lub wymianę w następnym dniu roboczym (np. 8x5xNBD).
  5. Jeśli godzinna przerwa w dostępności choćby jednego serwera jest biznesowo nie do zaakceptowania.
  6. Jeśli nie masz własnego zespołu IT lub masz tylko jednego fachowca.
  7. Gdy nie masz ubezpieczenia typu business interruption rozszerzonego o systemy IT i dane[1].
  8. Jeśli przywracanie z kopii zapasowej krytycznego serwera zajmuje kilka godzin.

Nawet jeśli tylko jeden z punktów pasuje do sytuacji jaką masz w firmie, powinieneś poważnie rozważyć usługi z zakresu disaster-recovery, np. DRaaS. Jeśli pasujących punktów jest więcej (wyłączając oczywiście pkt. 5 i 7), wówczas ryzyko wystąpienia przestoju jest bardzo wysokie. Kopia zapasowa jest niezbędna, jednak nie przywróci normalnego funkcjonowania, gdy pojawi się problem sprzętowy. W takiej sytuacji potrzebny jest szybki start na innym sprzęcie np. w zapasowej lokalizacji lub w chmurze publicznej dostawcy nawet w ciągu 15 minut.

[1] na dzień pisania tego artykułu w Polsce nie znalazłem takiej oferty.

Od kogo DRaaS w Polsce? Lista dostawców DRaaS

Od kogo DRaaS w Polsce? Lista dostawców DRaaS

Lista ta powstała w bólach. Znalezienie polskiego dostawcy DRaaS gotowego do natychmiastowego świadczenia usługi nie jest łatwe. Najpierw trzeba odszukać tych, którzy wiedzą o czym mówią. Następnie wyłuskać nielicznych, którzy mają gotowe usługi. Chwilami z badacza zmieniałem się w detektywa. W efekcie lista jest krótka, a na dodatek wcale nie miała powstać…

Klient wrzucił mnie na minę. Zostałem poproszony o wsparcie w procesie wyboru dostawcy DRaaS (Disaster Recovery as a Service). Szczerze, od razu podałem kandydata. Klient jednak chciał sam dokonać wyboru. Potrzeba trzech dostawców. Pomyślałem, że to banał. A potem zaczęła się jazda. I tak, niejako mimochodem, powstał pomysł sporządzenia listy dostawców DRaaS w Polsce.

Ważna rzecz – kryteria wyboru. Prowadzony projekt dostarczył mi inspiracji. Oto klient chciał by dostawcy byli krajowi oraz by zastosowanie miało nasza polska legislacja. Najważniejsze jednak, aby przetwarzanie danych było w granicach RP – czyli DRaaS w polskiej chmurze. Drugie kryterium to gotowość do świadczenia usługi. Tylko dostawcy, którzy deklarowali, że są w stanie w ciągu 48h udostępnić usługę do testów trafili na listę. Chodziło o to by wyłonić usługodawców mających gotowe środowisko w architekturze wielu najemców. Oferty takich firm istotnie różnią się cenowo od propozycji dostawców projektowych.

Dla porządku muszę też napisać, że praktycznie każde centrum danych może zaoferować usługę centrum zapasowego (DRC, DR Site), a czasem także wirtualnego centrum zapasowego (VDRC). Ten zakres usług to jednak nie SaaS (poziom aplikacji), czyli nie DRaaS. To w zasadzie wynajęcie miejsca w szafach (kolokacja), transmisja danych oraz najem sprzętu, i/lub licencji. To tradycyjne podejście do odtwarzania po awarii, podejście kosztowniejsze.

Nie wszystko złoto co się świeci. Proszę się nie dziwić, że w zestawieniu nie ma wielu rynkowych graczy. Owszem, o usługach z zakresu Disaster-recovery piszą prawie wszyscy, jest to jednak bardziej działanie policzone na zyskanie ruchu organicznego w wyszukiwarce Google (SEO), niż faktyczna oferta. W internecie znaleźć można też dostawców, którzy niefrasobliwie miksują definicje (o tym tutaj), niestety to także utrudnia zadanie poszukującym dostawcy konkretnej usługi.

Aktualizacja z 30-09-2019. Nowa lista dostawców, uwzględniająca również oferty projektowe znajduje się w tym artykule.

Planowanie odtwarzania po awarii – 7 grzechów głównych

Planowanie odtwarzania po awarii – 7 grzechów głównych

Jako samozwańczy „ewangelista” z zakresu ciągłości działania – czuję się usprawiedliwiony sięgając po katechizm 😉 Nie będę jednak prawił kazań. Opowiem tylko o typowych błędach jakie towarzyszą planowaniu odtwarzania po awarii, pamiętając przy tym o lekkostrawnej formie.

    1. Pycha. Nam się nic nie przytrafi. Zadziwiająco często spotykam menadżerów którzy jak mantrę powtarzają: „Przecież nigdy się to nie zdarzyło, po co więc chronić się przed takim ryzykiem?” Wtedy zalecam BIA (Analiza wpływu na biznes), która wprost odpowiada na pytanie czy warto czy też nie.
    2. Chciwość. Ta inwestycja nie przyniesie pieniędzy. Biznes nie lubi inwestować gdy nie widzi policzalnych zwrotów. Ciągłość działania porównać można do polisy ubezpieczeniowej, gdzie nakłady to koszt. Niestety, nie wiadomo, czy zaangażowane środki się zwrócą – czyli czy na przykład dzięki nim uratujemy organizację od przestoju. Pozostaje chłodna analizy ryzyk i ich wpływu na biznes oraz kosztów przestoju.
    3. Nieczystość. Nadmiarowość to nie odtwarzanie po awarii. Posiadanie klastra wysokiej dostępności, wyeliminowanie pojedynczych punktów awarii infrastruktury czy świetnie zabezpieczone centrum danych to solidny fundament ciągłości działania. Nie jest to jednak ochrona przed każdym ryzykiem. Przeciętny informatyk wyrwany ze snu bez wahania wskaże kilka scenariuszy, które zatrzymają IT Twojego przedsiębiorstwa.
    4. Zazdrość. Pomijanie właścicieli procesów. Zapominamy, lub co gorsza nie chcemy włączyć do planowania wszystkich interesariuszy. To strzał w kolano. Bez ich wiedzy nie będzie skutecznego odtworzenia po awarii.
    5. Nieumiarkowanie. Wszystko jest krytyczne. Klasyka. Zwykle, gdy zespół IT arbitralnie decyduje o tym, jakie zasoby mają być zabezpieczone na wypadek awarii, mamy sytuację, w której zasoby centrum zapasowego równe są zasobom centrum podstawowego.
    6. Gniew. Dlaczego działa tak wolno? Aspekt wydajności środowiska zapasowego jest częstym zarzewiem konfliktów wewnętrznych i zewnętrznych. Pamiętajmy, że to proteza, niezbędna do czasu powrotu stanu normalnego. Mamy podtrzymać procesy krytyczne. Poza tym testujmy praktycznie nasz plan odzyskiwania po awarii.
    7. Lenistwo. Zbytnie zaufanie do dostawcy DRaaS. Odtwarzanie po awarii jako usługa wymaga zaangażowania każdej strony umowy. Dostawca odpowiada za technologię i zasoby po swojej stronie. My natomiast, zadbajmy o uruchomienia testowe czy też cykliczne aktualizujmy plan odtwarzania po awarii. Przy okazji, zmianie może ulec zapotrzebowanie na zasoby dostawcy.

Czy DRCaaS = DRaaS? Zapasowe centrum danych

Czy DRCaaS = DRaaS? Zapasowe centrum danych

Disaster Recovery Center lub zamiennie DR Site, to po prostu zapasowe centrum danych. Miejsce w którym utrzymujemy sprzęt podobny lub tożsamy z tym z ośrodka podstawowego. Idea jest taka, aby w razie awarii podstawowego centrum danych możliwie szybko uruchomić nasze systemy i aplikacje z ośrodka zapasowego. Dodawanie do DRC czy do DRS członu „as a service” (jako usługa), oznacza, że może chodzić o DRC w wirtualnym wydaniu.

No dobrze, co to oznacza? Przyjmijmy, że mamy dostawcę, który oferuje nam Zapasowe Centrum Danych. Zazwyczaj jest to kawałek miejsca w szafie lub wiele szaf zlokalizowanych w Centrum Danych. Miejsce to, z natury rzeczy spełnia określone kryteria jakości usług. Głównie chodzi o nadmiarowość wszelkich systemów, poczynając od chłodzenia, zasilania, gaszenia, a na przyłączach telekomunikacyjnych i energetycznych kończąc. W klasycznym podejściu instalujemy tam nasze serwery. Oznacza to jednak, że dublujemy naszą infrastrukturę. Możemy „zaoszczędzić” decydując się na odwzorowanie częściowe, tylko dla zasobów krytycznych. W takim przypadku mamy zarówno koszty inwestycji jak i powiększone koszty operacyjne, bo trzeba płacić za miejsce w centrum danych dostawcy.

Innym rozwiązaniem jest DRCaaS lub DRSaaS. Różnica w stosunku do DRC/DRS polega na tym, że dostawca daje nam zasoby sprzętowe w postaci wirtualnych przydziałów w ramach własnych zasobów fizycznych. I tak, zamiast serwera otrzymujemy wirtualny serwer, zamiast przełącznika – przełącznik wirtualny, itd. Całość zasobów z naszego ośrodka podstawowego odwzorowujemy w przydzielonym przez dostawcę środowisku. Zwykle dostawcy oddają nam interfejs, dzięki któremu informatycy mogą zbudować zapasowe środowisko samodzielnie.

No i na deser odpowiedź na pytanie z tytułu, czy DRCaaS = DRaaS? Otóż nie – to są różne, choć funkcjonalnie podobne usługi. DRC jako usługa, to takie wirtualne centrum danych, które konfigurujemy na przykład dla potrzeb disaster recovery, ale nie tylko. Tymczasem DRaaS to usługa skupiona przede wszystkim na utrzymaniu ciągłości działania wirtualnego środowiska IT klienta. Zwykle usługa jest łatwa w implementacji, gdyż bazuje na znanej technologii najczęściej powiązanej z tą, używaną w środowisku informatycznym klienta. Obie usługi są też zwykle inaczej rozliczane. Na koniec można napisać, że DRaaS może być częścią usługi DRCaaS, ale nie na odwrót.

Chmura publiczna czy własne zasoby IT? A może to i to, czyli hybryda?

Chmura publiczna czy własne zasoby IT? A może to i to, czyli hybryda?

Prędzej czy później każdy stanie w obliczu wyboru – wynajmować czy kupować. Ciekawe, że decyzje zwykle zapadają w oparciu o różne obliczenia. Pytanie tylko, czy całkowity koszt posiadania (TCO) powinien być jedynym kryterium wyboru? Poza tym, czy aby na pewno dobrze porównujemy koszty, a więc czy porównujemy „jabłka do jabłek”? Na koniec, czym jest właściwie hybryda w przypadku chmury?

Decyzja o tym co wybrać, zawsze zależna powinna być od kontekstu, czyli od zadań jakie stawiamy przed systemami IT. Przykładowo, jeśli priorytetem jest szybki dostęp do bazy danych lub aplikacji dla potrzeb dużego zespołu lokalnego, a architektura rozwiązania jest sprzed kilku lat (najczęściej klient-serwer), wówczas trzymanie serwerów w siedzibie firmy ma uzasadnienie. Inaczej jest w przypadku zastosowań Internetowych. Jeśli do naszych systemów mają sięgać rozproszeni terytorialnie pracownicy, klienci albo partnerzy. Jeśli metodą dostępu będzie przeglądarka internetowa lub aplikacja na smartfona, wówczas umiejscowienie serwerów czy też wirtualnych maszyn w centrum danych operatora, jest lepszym rozwiązaniem.

Porównanie TCO, to następny krok. Dlaczego chmura publiczna w arkuszu kalkulacyjnym kosztuje więcej niż własne zasoby IT? W tym miejscu zazwyczaj umyka nam, że chmura publiczna to cały szereg składowych. Nie pamiętamy o nich, bo nie przypisujemy ich do operacji IT. Porównując TCO, uwzględnijmy zatem następujące koszty:

  1. zaangażowanego kapitału (inwestycja);
  2. utrzymania, konserwacji i napraw sprzętu sieciowego i serwerowego;
  3. licencji oraz opłat utrzymaniowych;
  4. pracy własnego zespołu lub usług obcych związanych z utrzymaniem sprzętu oraz administracji warstwą wirtualizacji czy systemów operacyjnych;
  5. utrzymania serwerowni, w tym:
  • utrzymanie, konserwacje i naprawy systemu zasilania awaryjnego,
  • konserwacje i naprawy klimatyzacji,
  • zużycie energii elektrycznej przez sprzęt IT oraz urządzenia infrastruktury serwerowni,
  • ubezpieczenie majątku.

A co z gdyby połączyć jedno z drugim? Czyli, nadal utrzymywać trochę zasobów informatycznych u siebie lokalnie, szczególnie tych do których dostęp musi być bardzo szybki. Równolegle korzystać z wybranych usług chmury publicznej, np.: w zakresie ciągłości działania (DRaaS, BaaS), czy kolokacji albo najmu wirtualnych serwerów (IaaS)? Jak się okazuje, to częsta praktyka, która być może stanie się standardem. Zgodnie z definicją, to chmura hybrydowa, czyli połączenie własnego środowiska informatycznego (serwerów) z chmurą publiczną usługodawcy.