Viability sp. z o.o.

Jaki jest koszt nienaruszalności kopii zapasowych?

5 kwietnia 202612 maja 2026

Gdy znamy metodykę ataku malware i mamy świadomość, że celem pierwszoplanowym są kopie zapasowe, motywacji do aktywnej ochrony infrastruktury backupu zwykle nie brakuje. Pozostaje kwestia, jak się do tego zabrać, aby osiągnąć zadowalający efekt i jakie to wygeneruje nakłady? Warto pamiętać, że bezpieczeństwo kopii zapasowych jest funkcją wielu działań, a nie jednego czynnika. Mimo to przedstawię drogę na skróty, która na początek daje najwięcej korzyści. Mowa będzie o nienaruszalnych repozytoriach na kopie zapasowe.

Czym jest nienaruszalność kopii zapasowych?

„NIENARUSZALNOŚĆ backupu to zdolność systemu kopii zapasowych do zagwarantowania, że utworzone kopie pozostaną integralne (niezmienione), nieusuwalne i gotowe do odtworzenia przez cały wymagany okres retencji (przechowywania) – niezależnie od awarii sprzętowych, błędów ludzkich czy celowych ataków.”

Źródło definicji: https://viability.pl/blog/nienaruszalna-kopia-zapasowa/

Skoro kopie zapasowe mają być de facto nietykalne przez zadany czas, pozostaje pytanie, jak to w praktyce zrealizować?

Kluczowe czynniki sukcesu w bezpieczeństwie backupu

Bezpieczeństwo backup osiąga się poprzez synergię 4 obszarów:

Architektura systemu. Właściwe zaprojektowanie i wykonanie systemu backupu zgodnie z podejściem Secure by Design, gdzie bezpieczeństwo jest fundamentem projektu, a nie dodatkiem po fakcie. Kluczowa jest segmentacja, czyli wydzielenie systemu backupu i repozytorium do osobnych stref sieciowych, tak by zminimalizować powierzchnię ataku i ograniczyć zasięg ewentualnego włamania.
Bezpieczne repozytorium. Czyli pamięć masowa, którą dzisiaj może być serwer lub usługa chmurowa, honorująca politykę retencji naszych zadań backupu. Istotne w tym jest, by mechanizm niezmienności był natywny, a więc wbudowany w system plików, storage lub API, a nie zapewniony wyłącznie przez oprogramowanie backupowe (które można odinstalować).
Ograniczanie uprawnień. Stosowanie zasady minimalnych przywilejów i polityki Zero Trust. W praktyce oznacza, że tworzymy konta z uprawnieniami wystarczającymi do działania. Nadto, zakładamy z góry, że naruszenie bezpieczeństwa nastąpi, więc każdy dostęp wymaga weryfikacji, a krytyczne operacje jak usunięcie kopii powinny wymagać zgody dwóch osób (zasada czterech oczu).
Testowanie backupu. Cykliczne odtwarzanie kopii zapasowych i weryfikacja integralności danych plus profilaktyczne skanowanie silnikiem antywirusowym.

Bezpieczne repozytorium, czyli co?

Repozytorium dla backupu musi zapewniać niezmienność danych najczęściej przez mechanizm WORM (Write Once Read Many) lub równoważny. Rzecz jasna, nie w nieskończoność, lecz zgodnie z naszą polityką backupu. A konkretnie to retencja określa nam jak długo mamy przechowywać kopie zapasowe. Jeśli masz 30-dniową retencję, możesz wrócić do stanu danych sprzed miesiąca. Jeśli incydent bezpieczeństwa lub błąd wykryjesz po 31 dniach, tego stanu danych już nie ma.

No dobrze, to teraz jakie repozytorium najlepiej, przy rozsądnym budżecie zrealizuje nasze cele. Oto przykłady, które różnią się modelem kosztowym: lokalne to głównie CapEx (sprzęt i licencje), a chmurowe to OpEx (subskrypcja). Obie ścieżki prowadzą do tego samego celu.

Repozytorium lokalne (on-prem):
- Veeam Hardened Repository (uniwersalne).
- Scality ARTESCA (uniwersalne).
Repozytorium chmurowe (cloud):
- Object Storage – AWS S3 lub Azure Blob (uniwersalne),
- Veeam Data Cloud Vault (dla Veeam).
- Veeam Cloud Connect (dla Veeam).

Jak zacząć, żeby szybko zyskać dużo?

Najwięcej rezultatów przy minimalnych nakładach osiągniesz przechowując backup lokalnie na niezmiennym repozytorium (immutable storage), a dodatkowo kopiując backup do repozytorium poza siedzibą (Off-site Backup). W ten sposób dane będą zabezpieczone przed sporą grupą typowych wektorów ataków.

Gdy Twój system backupu pochodzi od Veeam, masz do wyboru natywnie wspierany Veeam Cloud Connect (usługi realizowane przez partnerów Veeam), albo Veeam Data Cloud Vault (usługa oparta na AWS i Azure oferowana przez Veeam). Jeżeli masz system backupu od innego producenta, to zawsze możesz skorzystać ze zdalnego magazynu obiektowego w chmurze (S3 Object Storage). Która opcja jest najtańsza i którą warto wybrać? O tym w następnym akapicie.

Ile kosztuje bezpieczeństwo backupu?

Backup to de facto nadmiarowość w zakresie danych, czyli tworzenie kopii zapasowych to dublowanie stanu danych produkcyjnych i obsługujących je systemów. Jeżeli uwzględnić czas przechowywania, a nawet osiągnięte oszczędności z tytułu deduplikacji i kompresji kopii to może okazać się, że backup i tak wymagał będzie 2 lub nawet 3 razy więcej miejsca na pamięci masowej niż dane podstawowe.

Czas na wyliczenia. Przyjmijmy założenie, że mamy 20 TB danych produkcyjnych, co przy retencji 30 dni pozwala przyjąć, że wystarczy nam 50 TB repozytorium na backup. Poniżej opcje spełniające te warunki.

Repozytoria lokalne (on-prem):

🟪 Veeam Hardened Repository | Podstawowy serwer z kontrolerem macierzowym (RAID6) z 5 dyskami SAS 18 TB, co daje nam 54 TB przestrzeni na backup. Licencja na system jest bezpłatna | Przeciętny koszt: 43 000 zł netto, co przy amortyzacji na 3 lata daje22 zł/1 TB/ m-c + koszt energii*.

🟪 Scality ARTESCA (S3 Object Storage) | W przypadku tego magazynu obiektowego musimy zastosować 12 dysków SAS 6 TB, aby zagwarantować dalszą rozbudowę oraz o wiele droższą konfigurację sprzętową (między innymi – 256 GB RAM) ze względu na technologię zapisu danych (erasure-coding). Miejsce na backup ok. 55 TB. Licencjonowanie rozliczane jest za każdy TB | Przeciętny koszt: 87 000 zł netto, co przy amortyzacji na 3 lata daje 44 zł/1 TB/m-c + koszt energii*.

Repozytoria chmurowe (cloud):

🟦 S3 Object Storage – AWS S3 / Azure Blob (uniwersalne) | Oferta w zakresie obiektowej pamięci masowej jest bardzo bogata. Analizując ceny przyjąłem usługi typu „rzadki dostęp”, co limituje wolumen odtworzeni danych z backupu i przyjąłem, że nie nastąpi rozliczenie za egress. | Średni koszt usługi: 45 zł netto/1 TB/m-c.

🟦 Veeam Data Cloud Vault (dla Veeam) | Natywnie rozwiązanie dla Veeam Backup & Replication w dwóch wariantach:

Veeam Data Cloud Vault Foundation (Core Region) | Niezawodność na poziomie „11 dziewiątek”. Odtwarzanie limitowane, więc mogą się pojawić koszty dodatkowe. | Koszt usługi: 34 599 zł netto za rok, co daje ok. 58 zł/1 TB/m-c. >>> Skalkuluj u nas.
Veeam Data Cloud Vault Advanced (Core Region) Niezawodność na poziomie „12 dziewiątek”. Odtwarzanie bez limitów. | Koszt usługi: 59 199 zł netto za rok, co daje 99 zł/1 TB/m-c. >>> Sprawdź cenę u nas.

🟦 Veeam Cloud Connect (dla Veeam) | Ceny są zróżnicowane, bo zależne są od polityki cenowej partnerów programu VCSP. Zwykle mamy dwa składniki cenowe: storage i licencja połączeniowa rozliczana za VM/serwer (do kalkulacji przyjąłem 50 VM i 50 TB). | Koszt usługi: 5 150 zł netto/m-c, czyli 103 zł /1 TB/m-c.

Wnioski końcowe

Jak widać, najtańszą formułą na pozyskanie nienaruszalnego repozytorium jest lokalny Veeam / Linux Hardened Repository. W dodatku, gdy użyjemy jakiegoś starszego, wycofanego z użytkowania serwera, inwestycja sprowadzić się wyłącznie do kosztu zakupu dysków HDD + koszt energii elektrycznej. Uzyskanie immutable storage w cenie 22 zł/1 TB jest najtańszą możliwą opcją (dla block storage).

Jeżeli Capex odpada albo zależy nam na uruchomieniu nienaruszalnego repozytorium w ciągu godziny, wówczas do wyboru mamy chmurę z dość powszechną ofertą w zakresie S3 Object Storage. Cena repozytorium tego typu, przyjmując typowe użytkowanie pod backup nie powinna przekroczyć 45 zł/1TB m-c.

^{* Mały serwer może generować 250W ciągłego poboru, co przy polskich cenach prądu (~1,00 zł/kWh) daje ok. 108 zł/miesiąc (w przykładzie podnosi to cenę storage o ok. 2 zł / 1 TB / m-c).}

O pozostałych środkach, które prowadzą do wzmocnienia bezpieczeństwa backupu, a więc zwiększenia cyberodporności poczytać można w moim artykule na blogu firmowym.

Jak zapewnić ciągłość działania biznesów cyfrowych w trakcie wojny w cyberprzestrzeni?

23 lutego 202212 marca 2025

Usługi cyfrowe są nieodłącznym elementem naszego życia. Przyzwyczajeni jesteśmy do ich nieustannej dostępności. Dlatego nie jest wcale łatwo budować scenariusze na wypadek zakłócenia funkcjonowania systemu bankowego, niedostępności Internetu, czy na przykład całodniowego blackout’u. Biorąc jednak pod uwagę doświadczenia innych państw (np. Estonii) oraz „warunki wojenne”, należy uwzględnić i takie czynniki w swoich planach BCP. Chodzi o to, by skutecznie chronić ciągłość działania biznesów cyfrowych.

Mamy od wczoraj alarm CHARLIE–CRP i całkiem prawdopodobne, że już wkrótce będzie to DELTA-CRP. Dla instytucji odpowiedzialnych za obiekty infrastruktury krytycznej w naszym kraju, takich jak: banki, elektrownie, firmy telekomunikacyjne, elektrociepłownie, itd., oznacza to zwiększoną gotowość i konieczność prowadzenia całodobowych dyżurów. Chodzi o zapewnienie szczególnego nadzoru w obszarze bezpieczeństwa i ciągłości działania systemów. Czy w związku z tym i my powinniśmy w jakiś sposób zabezpieczyć ciągłość działania biznesów cyfrowych na wypadek wojny w cyberprzestrzeni?

Wektory ataków w cyberprzestrzeni skierowane są na cele, których zakłócenie funkcjonowania odczują duże społeczności. Przykładowo, niedostępność niektórych usług bankowych albo ogrzewania i ciepłej wody na określonym terenie. Mogą to być również długotrwałe wyłączenia energii elektrycznej. Jak widać na przykładach, mimo że atak nie będzie wymierzony w nasz biznes, w jego efekcie może nastąpić zakłócenie ciągłości działania. Jak przeciwdziałać takim sytuacjom?

Oto kilka sposobów zwiększających odporność naszego biznesu cyfrowego na przestój, spowodowany skutkami wojny w cyberprzestrzeni.

Dublowanie dostawców. Wykorzystajmy rozproszony charakter usług internetowych. W Internecie nie da się po prostu wyciągnąć „globalnej wtyczki”. Dlatego, jeżeli masz e-commerce zlokalizowany w Polsce, to replikuj całą witrynę do usługodawcy spoza RP lub na inny kontynent. Wykorzystaj darmowe usługi do ręcznego lub automatycznego zarządzania ruchem, np. CloudFlare. W razie problemów w Polsce, możesz łatwo przełączyć swoich klientów na swój sklep uruchomiony np. w USA.
System bezpieczeństwa. Skorzystaj z komercyjnych narzędzi zabezpieczających, jak na przykład: BitNinja, czy Imunify360, które automatycznie odetną Twoje aplikacje od wielu znanych zagrożeń, a w szczególności od miejsc w sieci o wątpliwej reputacji.
Monitorowanie w trybie ciągłym swoich aplikacji oraz SLA dostawcy. To da Ci szansę na szybką reakcję w razie ataku lub awarii po stronie usługodawcy. Jeżeli coś się stanie z Twoim sklepem, a masz replikę lub kopię, pozwoli Ci to szybko odtworzyć usługę w bezpiecznej lokalizacji. Monitorowanie możesz zorganizować przy pomocy: UptimeRobot lub UpDown.io.
Dodatkowe kanały płatności. Skorzystaj z bramek płatności niezależnych od polskiego systemu bankowego. Dość popularne na zachodzie systemy to PayPal i Stripe. W razie problemów z bankowością w Polsce, nadal będzie możliwe realizowanie transakcji płatniczych. W przypadku sprzedaży dóbr fizycznych ważne jest, aby zaplanować zapasowy łańcuch dostaw.
Kanały komunikacji kryzysowej. Warto zawczasu zorganizować alternatywne metody komunikacji, by zespół wiedział, jak ma się ze sobą porozumiewać w przypadku awarii operatorów GSM, czy niedostępności serwera pocztowego. Z pomocą może przyjść sporo darmowych narzędzi, jak na przykład komunikatory typu: Signal, Viber, Slack, Mattermost, itd.

Masz wątpliwości jak zabezpieczyć swój biznes cyfrowy i potrzebujesz szybkiej pomocy? Może zastanawiasz się, czy DRaaS lub DRC jest dla Ciebie? Skorzystaj z naszej darmowej konsultacji.

Ciągłość działania Centrum Danych

10 marca 202112 marca 2025

Od czasu do czasu, gdy dochodzi do katastrofy, czyli zdarzenia o naturze niszczącej, pojawia się pytanie o granice odpowiedzialności operatora Centrum Danych. Wówczas też, wiele osób z branży, samozwańczo przywdziewa szaty eksperta od Odtwarzania Awaryjnego rozumiejącego Ciągłość Działania Centrum Danych. Z takim nadaniem, bez pardonu biczuje zwykle nieszczęśnika. Zazwyczaj, chodzi o to, że w opinii „ekspertów”, wszystko powinno być zdublowane. Najlepiej replikowane do innego Data Center. Tylko, czy aby na pewno? Czy operator ośrodka przetwarzania może zabezpieczyć przed katastrofą każdego klienta?

Zacznę od przekrojowego przedstawienia usług świadczonych przez typowe Data Center, bo zrozumienie tego aspektu jest kluczowe. Nie jest tak, jak uważa wielu, że Centrum Danych zajmuje się głównie dostarczaniem chmury publicznej. Ba, większość biznesu dla typowego DC, to kolokacja, wynajem kiosków, czy całych komór. Dochodzą także tzw. dedyki, czyli instalacje serwerowo-sieciowe przygotowywane dla konkretnego klienta. Dopiero na końcu stawki są usługi przetworzone, repozytoria, archiwizacja, backup i chmura publiczna oraz prywatna plus różne usługi dodatkowe.

Widzicie już pewnie do czego zmierzam. Co usługodawca może wiedzieć o Planie Odtwarzania Awaryjnego klienta, który wynajmuje u niego 2 szafy rack postawione obok siebie? Operator świadczy w tym przypadku usługę kolokacji. Zapewnia szafy, dostarcza zakontraktowaną moc (prąd), realizuje połączenia sieciowe i dba odpowiednie warunki środowiskowe (temperatura, wilgotność powietrza, itp.). Natomiast, nie ma wiedzy o tym, co klient w tych szafach trzyma. Albo weźmy klaster serwerów dedykowanych, które klient odbiera do poziomu wirtualizatora. Czy taka usługa jest odporna na pożar Centrum Danych? Kompletnie nie! Chyba że klient wykupi sobie podobna usługę w innym DC i zsynchronizuje te zasoby. Może też robić kopie zapasowe lub nabyć usługę DRaaS. Ważne przy tym, by repliki składować w innym ośrodku. Zatem, czy operator Centrum Danych może samodzielnie zabezpieczyć klienta przed katastrofą? Bez jego chęci i woli, nie ma o tym mowy.

Trochę inaczej wygląda to z perspektywy hiperskalerów, które budują ośrodki przetwarzania wyłącznie na potrzeby swoich chmur. Jednak, nawet i w tym przypadku nic nie dzieje się samo.

Nie wiem, czy słyszeliście o „wspólnej odpowiedzialności” (shared responsibility)? Dostawcy chmury publicznej jasno definiują, za co odpowiadają przy każdym z typów usług. Gdy uruchamiamy serwer wirtualny (VPS), sami musimy zadbać o jego ciągłość działania. Służy temu na przykład Site Recovery (Azure), oczywiście to usługa dodatkowo płatna. Jeśli nie zdecydujemy się na takie zabezpieczenie, będziemy musieli pogodzić się z ewentualnymi konsekwencjami, w razie katastrofy.

Wszystko ma swoją cenę. Nie zapłacisz teraz, zapłacisz później, zwykle jeszcze więcej. Dlatego, analizując ryzyka, ważmy koszty ich materializacji. Zestawmy ze sobą, całkowite koszty przestoju oraz odtwarzania awaryjnego. Dodajmy konsekwencje utraty wizerunku i klientów. Porównajmy to z ceną usługi, nawet na 3 lata, która ten przestój skróci lub wyeliminuje. Dodajmy jeszcze do tego nasz święty spokój, który dostajemy w bonusie 🙂 . Taka jest właśnie recepta na ciągłość działania bez względu na to jakie Centrum Danych wybierzemy.

Czym się różni PaaS od hostingu?

24 stycznia 202119 grudnia 2021

PaaS (Platform as a Service) i współdzielony hosting są usługami dla zupełnie innych odbiorców, dlatego istotnie się różnią, pomimo pozornego podobieństwa. Platforma jako usługa ma konsolę z ilością ustawień przypominającą kokpit samolotu. Hosting z kolei bardziej przypomina pilota od Apple TV 😊 Kto korzystał z obu tych usług, nigdy ich nie pomyli. Nadmienię jednak, że ostatnio, szczególnie u największych usługodawców, oblicze hostingu trochę się zmienia.

Mniej więcej 20 lat temu zbudowałem biznes „hostingowy” B2B (nie podejmuje się tłumaczenia tej nazwy), i byłem wówczas w Polsce jednym z nielicznych dostawców. Sam od lat jestem użytkownikiem współdzielonego hostingu od GoDaddy (cPanel) i Zenbox. Jakieś 3 lata temu odkryłem alternatywę w postaci Platformy jako Usługi (PaaS). A w ubiegłym roku postanowiłem włączyć się do gry jako usługodawca PaaS. Poznałem zatem blaski i cienie każdego rozwiązania, w dodatku z obu perspektyw – dostawcy i klienta.

Zacznę od tego, że hosting nie spełnia kryteriów chmury. Otóż, według National Institute of Standards and Technology, chmurę definiuje kilka charakterystycznych elementów (str 2). O ile przy hostingu możemy mówić w jakimś stopniu o samoobsłudze, o tyle już o rozliczeniu za użycie, czy automatycznej skalowalności możemy zapomnieć. Hosting ma być prosty i ładnie opakowany. Zwykle klient dostaje do wyboru 3 sztywne pakiety, bo większy wybór wywołuje niepotrzebny ból głowy. Niekiedy usługodawca umożliwia klientowi przełączanie się między pakietami, trzeba to jednak zrobić ręcznie. Tyle w kwestii skalowalności, a teraz przejdźmy do kwestii rozliczeń.

Cechą podstawową hostingu jest ryczałt. Zapewne ten fakt, jak i agresywna polityka cenowa dostawców sprawia, że hosting jest tak atrakcyjny dla klientów. Ale uwaga, bo tu jest haczyk. Jak wiemy z lekcji ekonomii, zasoby są zwykle ograniczone. Bardzo to uwydatnia się przy hostingu, gdzie współdzielenie mocy obliczeniowej, pamięci i przestrzeni dyskowej nie zawsze odbywa się w sposób uczciwy. Każdy dostawca zakłada jakąś nadsubskrypcję usług. Przyjmuje zatem, że kupujący nie wykorzysta 100% zasobów przypisanych mu w ramach pakietu. Mało tego, często przyjmuje się, że klient sięgnie po nie więcej niż 10-20%. Przy kilkuset klientach to już spora oszczędność. I tu jest właśnie największa słabość tej oferty.

No dobrze, a co z odpornością na awarie? Wybierając ofertę dostawców hostingu nie mamy zupełnie kontroli nad poziomem niezawodności usługi. Owszem, możemy robić backup bazy danych, czy kopię zapasową plików, jednak na tym kończy się nasza lista możliwości.

Takie opcje jak balansowanie ruchu, klastry wysokiej dostępności, regiony geograficzne, replikacja czy autoskalowalność to domena rozwiązań klasy PaaS lub IaaS, a więc chmury publicznej. W rezultacie, niezawodność usług hostingowych zależy od decyzji biznesowych dostawcy. Te decyzje są zwykle pokłosiem poziomu świadomości technicznej, nakładów oraz wynikającej z nich architektury rozwiązania.

Jak wygląda odtwarzanie awaryjne naszego e-commerce w sytuacji jakiegoś incydentu po stronie dostawcy hostingu? Oznacza najczęściej oczekiwanie aż usługa znowu zacznie działać. Można oczywiście podjąć próbę uruchomienia wszystkiego u innego usługodawcy, a potem zrobić przekierowanie domeny w serwerze nazw, ale będzie to proces żmudny i, może się okazać, że niepotrzebny. Tutaj trzeba oddać sprawiedliwość hostingodawcom, bo choć wpadki zaliczają, to zwykle przerwy w dostępności są krótkotrwałe. Gorzej, gdy wydarzy się coś katastrofalnego w skutkach. Wówczas, RTO może wynieść nawet kilka dni (wspomniana odbudowa w innym miejscu), a RPO może oznaczać zgubienie transakcji z 24 godzin, pod warunkiem, że kopie zapasowe bazy trzymamy w innym miejscu.

Spójrzmy na zagadnienie z perspektywy Platformy jako Usługi. Możliwości konfiguracyjne są bardzo rozbudowane, co sprawia, że nieobeznany użytkownik poczuje się zagubiony.

PaaS nie jest dla kogoś kto nie wie, co to jest Apache, NGINX, Varnish, PHP, Memcached, albo czym różni się baza SQL od NoSQL, czy skalowanie stanowe od bezstanowego. Nagrodą za tę wiedzę jest kontrolowana skalowalność, nadmiarowość i bezpieczeństwo usługi oraz spore możliwości.

Przyjmijmy, że aplikacja, którą mamy używać wymaga różnych, precyzyjnie skonfigurowanych bibliotek oprogramowania, aby działać optymalnie. W hostingu jest to właściwie niemożliwe, a w PaaS to podstawowa funkcjonalność. Podobnie jest z dynamicznym przydzielaniem większej ilości zasobów obliczeniowych. Gdy uruchomicie kampanię i nagle do Waszego sklepu „zajrzy” 1000x więcej klientów niż dotychczas, co wtedy? W 99% przypadków wasz dostawca hostingu wyświetli im komunikat błędu kategorii pięćset – np. limit zasobów, wewnętrzny błąd serwera, itp. Coś takiego nie wydarzy się jednak w przypadku PaaS. Chmura załatwia to w locie, dodając pamięć, moc, a jak trzeba także kolejne serwery. Dostaniecie też powiadomienie, że obciążenie wzrosło, aby ewentualnie samemu zdecydować jak ma się dalej zachować wasze środowisko.

Sceptyk od razu przyczepi się, że to pewnie sporo kosztuje. I tak i nie. Owszem, nie ma ryczałtu, więc jest trochę niepewności dotyczącej tego, jaki będzie ostateczny koszt. Dużo zależy od sposobu korzystania z usługi. Moje analizy wykazały, że dla podobnych usług ceny są prawie takie same. W GoDaddy na przykład ryczałt roczny za 1 publiczny adres IP to koszt 287 zł netto. Na platformie PaaS Cloudlets.Zone to 3 gr za godzinę, a więc 262 zł brutto za rok. W dodatku nie trzeba przedpłacać. Jeśli uwzględnić możliwość usypiania środowisk w chmurze to już naprawdę hosting staje się mało opłacalny. Po co na przykład system do wideokonferencji ma działać całą dobę? Można go przecież automatycznie zagasić, powiedzmy o 22:00, by potem kalendarzowo włączyć o 7:00.

Mam nadzieję, że lektura tego artykułu dała odpowiedzi na postawione w tytule pytanie. Choć hosting pojawił się o wiele wcześniej, niż moda na chmurę, wciąż jeszcze ma się dziś dobrze, z resztą nie tylko w Polsce. Tym niemniej, wraz z rosnącymi potrzebami i świadomością klientów, PaaS może okazać się potencjalnym, bardzo ciekawym następcą rozwiązań hostingowych.

Hiperkonwergencja – zrób to sam (DIY)

5 czerwca 202019 grudnia 2021

Czy da się zbudować rozwiązanie serwerowe klasy korporacyjnej w oparciu o sprzęt dla małego i średniego biznesu? Zdecydowanie tak! Z pomocą przychodzi hiperkonwergencja, która coraz częściej zastępuje silosową architekturę konwergentną. Paliwem do zmiany podejścia jest nie tylko cena, ale coraz powszechniejsza konteneryzacja i architektura mikroserwisów. Dodatkowym bodźcem są zmiany pokoleniowe. Chodzi mi o słabą dostępność inżynierów, którzy potrafią zarządzać złożonymi środowiskami.

Zwyczajowo zacznę od definicji. Co to jest architektura konwergentna? Otóż, jest to ekosystem sprzętowo-aplikacyjny, składający się z serwerów, macierzy oraz sieci i zwykle też silnika wirtualizacji, ale nie jest on niezbędny. W takim podejściu, mamy do czynienia z siecią lokalną (LAN) i siecią dla pamięci masowej (SAN). Ta druga służy dedykowanej komunikacji serwerów z macierzą dyskową. Czym zatem jest hiperkonwergencja (HCI)? Jest uproszczeniem polegającym na połączeniu w jednym urządzeniu: mocy obliczeniowej oraz pamięci masowej. W tym przypadku konieczny jest silnik wirtualizacyjny (hiperwisor), stąd pochodzi pierwszy człon nazwy własnej tej architektury. W rozwiązaniach hiperkonwergentnych często eliminuje się sieć SAN, jako zbędną. Nadmienię, że w rozwiązaniach wysoko wydajnych HCI, szczególnie gdy zastosujemy najszybsze dyski półprzewodnikowe (NVMe), nadal separuje się sieć IP od sieci pamięci masowej. Warto podkreślić, że hiperkonwergencję jest możliwa dzięki pamięci definiowanej programowo (Software Definied Storage). SDS to metoda na zarządzanie rozproszonymi zasobami dyskowymi i sposób na nadmiarowość. Tyle teorii.

HCI można kupić od kilku znanych dostawców, jak: Nutanix, Dell, HPE, itd. Ja jednak, idąc „pod prąd” namawiam do metody – zrób to sam (DIY). Wówczas inwestycja wyjdzie, nawet połowę taniej! Można też zaplanować migrację z częściowym alokowaniem dla HCI swoich obecnych zasobów serwerowych. Wówczas najprościej (ale nie najtaniej), użyć technologii vSAN od VMware. Gdy wpadniesz na pomysł: „zrobię to na OpenSource”, rozważ krótką listę akronimów, które niechybnie poznasz i to zaraz na starcie: SDS, SAN, DRBD, RDMA, IPoIB, RoCE, IBoE, Ceph, NFS, SR-IOV, NFMeoF, itd. Jeśli masz mocny zespół, to wspaniale, na pewno dacie radę. W innym razie rekomenduję wybór dostawcy, który dostarczy know-how w postaci skonfigurowanego sprzętu i aplikacji. Dużo drożej nie będzie, ale na pewno szybciej i bez huśtawki nastrojów.