Jak przygotować politykę odzyskiwania danych? Przewodnik dla sektora MŚP 2018

Małe i średnie firmy stają przed wyjątkowymi wyzwaniami, jeśli chodzi o odzyskiwanie danych po awarii. Mają do czynienia z dużo mniejszym budżetem niż większe firmy, a jednocześnie muszą spełniać bardzo podobne oczekiwania dotyczące odzyskiwania danych.

Ponadto personel IT to często mały, ciężko pracujący zespół złożony z trzech lub czterech osób, który obejmuje wszystkie aspekty potrzeb IT organizacji. Wreszcie, zespół staje w obliczu zagrożeń 2018 roku, których zakres jest o wiele szerszy niż kiedykolwiek wcześniej, przede wszystkim ze względu na coraz częstsze i przebieglejsze ataki cybernetyczne.

Większość planów Disaster Recovery w dużych i małych firmach nie została oficjalnie spisana.  Tworzy je mieszanka najlepszych pomysłów i starań, które w razie katastrofy sprawią, że zespół IT zaczyna się zastanawiać, czy uda im się ponownie złożyć wszystko w całość, z różnym powodzeniem.

Plan DR dla małych i średnich przedsiębiorstw (MŚP)

Firmy MŚP tworząc politykę „reagowania w czasie awarii” powinny w pierwszej kolejności wziąć pod uwagę to, że dział IT ma bardzo szeroki zakres obowiązków i dodanie kolejnego tak kompleksowego zadania do ich listy nie będzie efektywne. Zamiast pisać złożony plan odzyskiwania danych po awarii, specjaliści IT powinni zacząć od niewielkich działań i skupić się na aplikacjach lub zestawach danych, które są najważniejsze dla organizacji.

Przede wszystkim powinny one podejść do procesu planowania „przywracania po awarii” fragmentów o niewielkich rozmiarach, przy czym każdy fragment musi być realnym, samodzielnym planem. W tym czasie pozostałe plany są opracowywane i ukończone.

Strategia DR dla małych i średnich firm

Począwszy od małych firm strategia ta jest również idealna dla sektora MŚP, o ile firmy wiedzą, od czego zacząć. Miejsce na początek to aplikacja, która jest najważniejsza dla organizacji. Dla przykładu, wiele organizacji odczuje, że poczta e-mail jest aplikacją o znaczeniu krytycznym i będzie chciała ją z powrotem w trybie online tak szybko, jak to możliwe. W przypadku innej organizacji serwer poczty e-mail może znajdować się poza siedzibą firmy, więc inna system, być może oparty na MS-SQL, będzie ważniejszy do odzyskania. W obu przypadkach proces planowania jest podobny. Po pierwsze, architekci muszą zdecydować, jaki jest realny czas przywracania dla tej aplikacji.

Istnieją dwa parametry, które należy zrozumieć: dopuszczalny/tolerowany okres czasu, w którym możemy uznać, że nie będziemy mieli danych biznesowych, często nazywany celem punktu odzyskiwania (RPO) oraz czas maksymalny jaki organizacja zakłada, że system/usługi zostaną przywrócone do działania (RTO).

Ograniczenie utraty danych wymaga większego nacisku na zapewnienie ich ochrony, a zapewnienie większej ochrony danych wymaga bardziej wydajnych narzędzi do tworzenia kopii zapasowych, które minimalizują transfer danych. IT potrzebuje rozwiązania, które może tworzyć backup na poziomie pliku podrzędnego, często nazywanego Changed Block Tracking (CBT) lub backupem przyrostowym na poziomie bloku (BLI).

Techniki te umożliwiają organizacji szybkie kopiowanie danych przy jednoczesnej minimalizacji czasu, w którym kopie zapasowe łączą się z aplikacją i minimalizują przepustowość  sieci wymaganej do wykonania transferu.

Ponadto, działy IT będą potrzebować swojego rozwiązania, aby zapewnić przejrzysty interfejs dla aplikacji uznanych za krytyczne (Exchange i / lub MS-SQL) w celu wykonania kopii zapasowej wysokiej jakości, podczas gdy aplikacja pozostaje w produkcji. Wreszcie, jeśli chodzi o odzyskiwanie, będą musieli zdecydować, czy na podstawie parametrów RTO będą w stanie zmienić pozycję danych w czasie, aby osiągnąć cel.

Spełnienie parametrów RTO jest funkcją tego, ile danych ma zostać przeniesionych, jaka przepustowość sieci jest dostępna i jak wydajne jest oprogramowanie do tworzenia kopii zapasowych w ruchu danych. W przypadku zbyt dużej ilości danych i niewystarczającej przepustowości, trzeba zwrócić uwagę na techniki takie jak recovery-inplace, gdzie wolumen kopii zapasowych może przedstawiać działający zestaw danych aplikacji bez konieczności przesyłania danych przez sieć.

Przed zakupem jakiegokolwiek nowego oprogramowania lub sprzętu ważne jest, aby dział IT przechodził ten proces z każdą z głównych aplikacji i zestawów danych, ustanawiając dla każdego z nich RPO i RTO, a następnie ocenił, na ile spełnia ich wymagania. Muszą również zrozumieć lukę między obecną rzeczywistością, a pożądaną przyszłością.

Po stwierdzeniu tej luki, planiści IT muszą przeanalizować rozwiązania, które zapewnią im pożądaną przyszłość RPO / RTO. Wreszcie, IT musi przedstawić te ustalenia organizacji, wyjaśniając, że ich wybory to (1) niewydawanie pieniędzy i dostosowywanie oczekiwań do rzeczywistości lub (2) inwestowanie w rozwiązanie, które umożliwi im spełnienie preferowanych celów RPO / RTO.

Metody DR dla Centrów danych małych i średnich firm

W ramach procesu DR, architekci IT muszą zrozumieć, jakie opcje są dla nich dostępne. Istnieje kilka specyficznych funkcji, o których muszą wiedzieć, aby upewnić się, że stanowią część potencjalnego nowego rozwiązania.

Wirtualizuj wszystko

Pierwszym punktem do rozważenia jest wirtualizacja. Zespoły IT w firmach z rynku MŚP powinny próbować wirtualizować wszystkie aplikacje i zestawy danych. Wirtualizacja posiada mnóstwo zalet, których nie można ignorować. Ważne są one w szczególności dla małych i średnich firmach. Większość głównych hypervisor’ów ma wbudowaną technologię CBT lub ułatwia producentowi backupu tworzenie własnej techniki BLI. Wirtualizacja ułatwia odzyskiwanie, ponieważ maszyny wirtualne można stosunkowo łatwo przenieść z jednego serwera fizycznego na drugi.

Replikacja vs. Backup

Drugim pytaniem jest, czy organizacja powinna wykorzystywać backup czy replikację. Krytyczne różnice między tymi dwiema technikami to częstotliwość ochrony i poziom retencji. Replikacja zapewnia częstszą ochronę i najkrótsze przechowywanie. Większość organizacji zazwyczaj korzysta z backupu, aby zapewnić ochronę fundamentów w całym przedsiębiorstwie i replikację dla konkretnych aplikacji wymagających wyższego poziomu ochrony i odzyskiwania.

Problem polega na tym, że tworzenie kopii zapasowych i replikacja tradycyjnie pochodzą od różnych dostawców, a zatem trzeba nimi zarządzać niezależnie od siebie. Potrzeba dwóch oddzielnych rozwiązań jest szczególnie frustrująca dla rynku MŚP, który zazwyczaj ma tylko jedną lub dwie aplikacje, które mogą uzasadnić możliwości replikacji. Na szczęście niektórzy producenci oprogramowania do backupu łączą teraz dwie funkcje w jeden produkt i interfejs, umożliwiając zespołom IT w firmach rynku MŚP wybór opcji najbardziej odpowiedniej dla ich środowiska.

Recovery-In-Place (odzyskiwanie na miejscu)

Recovery-In-Place uzupełnia replikację. Dane są nadal chronione w ramach procesu tworzenia kopii zapasowej i są przechowywane w architekturze i formacie kopii zapasowych. Jednak dzięki odzyskiwaniu na miejscu oprogramowanie ma możliwość utworzenia woluminu opartego na ostatniej znanej, dobrej kopii i zamontowania go bezpośrednio w magazynie kopii zapasowych, co oznacza, że ​​aplikacja może powrócić do usługi bez konieczności oczekiwania na przeniesienie danych w sieci. Architektura ochrony danych powinna również być w stanie replikować dane kopii zapasowej, w miarę ich zmiany, w zdalną lokalizację.

Odzyskiwanie w miejscu umożliwia organizacjom uruchamianie maszyn wirtualnych i wskazywanie ich w miejscu przechowywania kopii zapasowych w lokalizacji zdalnej, dzięki czemu aplikacje mogą powrócić do usługi niemal natychmiast po zgłoszeniu awarii.

Kluczową różnicą między tworzeniem kopii zapasowych, a odzyskiwaniem w miejscu i replikacją jest częstotliwość zdarzeń ochrony i czas wymagany do utworzenia woluminu wirtualnego w magazynie kopii zapasowych. W przypadku większości małych i średnich firm miejsce odzyskiwania powinno być odpowiednie dla większości potrzeb związanych z odzyskiwaniem aplikacji.

Podsumowanie

Potrzeba wdrożenia i utrzymania strategii DR jest bardziej realna niż kiedykolwiek w przypadku centrów danych MŚP. Technologie takie jak wirtualizacja, odzyskiwanie granularne i odzyskiwanie danych „na miejscu” obniżają koszty szybkiego odzyskiwania. Wyzwaniem stojącym przed IT jest to, że ich centra danych są już “w ruchu”. Firmy z sektora MŚP do stworzenia planu „odzyskiwania po awarii” powinny pomyśleć nad stworzeniem zestawu planów dotyczących każdej aplikacji z osobna.

Czym jest VMware DRS Cluster?

Klaster to grupa hostów połączonych ze sobą specjalnym oprogramowaniem, które czyni je elementami jednego systemu. Co najmniej dwa hosty (zwane również węzłami) muszą być połączone, aby utworzyć klaster. Po dodaniu hostów do klastra ich zasoby stają się zasobami klastra i są zarządzane przez klaster.

Najczęstsze typy klastrów VMware vSphere to klastry o wysokiej dostępności (HA) i rozproszonego zarządzania zasobami (Distributed Resource Scheduler – DRS). Klastry HA zostały zaprojektowane w celu zapewnienia wysokiej dostępności maszyn wirtualnych i usług na nich działających; jeśli host zawiedzie, natychmiast uruchamia ponownie maszyny wirtualne na innym hoście ESXi. Klastry DRS zapewniają równoważenie obciążenia między hostami ESXi. W tym artykule dogłębnie zbadamy system klastra DRS.

Jak działa klaster DRS?

Distributed Resource scheduler (DRS) jest typem klastra VMware vSphere, który zapewnia równomierne obciążenie poprzez migrację maszyn wirtualnych z obciążonego hosta ESXi do innego hosta, który ma wystarczającą ilość zasobów obliczeniowych, podczas gdy maszyny wirtualne nadal działają. Takie rozwiązanie jest używane, aby zapobiec przeciążeniu hostów ESXi.

Maszyny wirtualne mogą mieć nierównomierne obciążenia w różnym czasie, a jeśli host ESXi jest przeciążony, zmniejsza się wydajność wszystkich maszyn wirtualnych działających na tym hoście. W takiej sytuacji klaster VMware DRS zapewnia automatyczną migrację VM.

Z tego powodu DRS jest zwykle używany jako dodatek do HA, łączący przełączanie awaryjne z równoważeniem obciążenia. W przypadku przełączania awaryjnego maszyny wirtualne są restartowane przez moduł HA na innych hostach ESXi, a system DRS, wykorzystując dostępne zasoby obliczeniowe, zleca odpowiednie rozmieszczenie maszyn wirtualnych.

Technologia vMotion jest używana do migracji na żywo maszyn wirtualnych – dla użytkowników i aplikacji proces ten jest niezauważalny.

Pule zasobów służą do elastycznego zarządzania zasobami hostów ESXi w klastrze DRS. Można ustawić ograniczenia procesora i pamięci dla każdej puli zasobów, a następnie dodać do nich maszyny wirtualne.

Na przykład można utworzyć jedną pulę zasobów o wysokich limitach zasobów dla maszyn wirtualnych programistów, drugą pulę z normalnymi limitami dla maszyn wirtualnych testerów i trzecią pulę z niskimi limitami dla innych użytkowników. vSphere pozwala tworzyć pule zasobów potomnych i nadrzędnych.

Kiedy są używane klastry DRS?

Rozwiązanie DRS jest zwykle używane w dużych wirtualnych środowiskach VMware z nierównomiernymi obciążeniami maszyn wirtualnych w celu zapewnienia racjonalnego zarządzania zasobami. Użycie kombinacji DRS i HA skutkuje uzyskaniem klastra o wysokiej dostępności z równoważeniem obciążenia. DRS jest również przydatny do automatycznej migracji maszyn wirtualnych z serwera ESXi wprowadzonego w tryb konserwacji przez administratora.

Ten tryb musi być włączony, aby serwer ESXi wykonywał operacje konserwacyjne, takie jak aktualizacje oprogramowania układowego, instalowanie poprawek zabezpieczeń, aktualizacje ESXi itp. Nie ma żadnych maszyn wirtualnych działających na serwerze ESXi wchodzącym w tryb konserwacji.

Funkcje klastrowania DRS

Główne funkcje klastrowania w DRS to równoważenie obciążenia, zarządzanie rozproszonym zasilaniem i zasady powinowactwa.

Load Balancing to funkcja optymalizująca wykorzystanie zasobów obliczeniowych (CPU i RAM). Wykorzystanie zasobów procesora i pamięci przez każdą maszynę wirtualną, a także poziom obciążenia każdego hosta ESXi w klastrze, jest stale monitorowane. DRS sprawdza zapotrzebowanie na zasoby maszyn wirtualnych i określa, czy istnieje lepszy host dla maszyny wirtualnej.

Jeśli istnieje taki host, DRS wydaje polecenie migracji maszyny wirtualnej w trybie automatycznym lub ręcznym, w zależności od ustawień. DRS generuje te zalecenia co 5 minut, jeśli są konieczne. Poniższy rysunek ilustruje przeprowadzanie migracji VM DRS w celu równoważenia obciążenia.

Distributed Power Management (DPM) to funkcja oszczędzania energii, która porównuje pojemność zasobów klastra z zasobami wykorzystywanymi przez maszyny wirtualne w klastrze. Jeśli w klastrze jest wystarczająca ilość wolnych zasobów, program DPM zaleca migrację maszyn wirtualnych z lekko obciążonych hostów ESXi i wyłączenie tych hostów. Jeśli klaster potrzebuje więcej zasobów, pakiety wake-up są ponownie wysyłane do hostów zasilania.

Aby to działało, serwery ESXi muszą obsługiwać jeden z następujących protokołów zarządzania energią: Wake-On-LAN (WOL), Hewlett-Packard Integrated Lights-Out (iLO) lub Intelligent Platform Management Interface (IPMI). Dzięki DPM klastra DRS można zaoszczędzić do 40% kosztów energii elektrycznej.

Zasady podobieństwa – umożliwiają kontrolę nad umieszczaniem maszyn wirtualnych na hostach. Istnieją dwa typy reguł, które umożliwiają utrzymywanie maszyn wirtualnych w jednym miejscu lub rozdzielenie:

  • zasady powinowactwa lub anty-powinowactwa pomiędzy poszczególnymi maszynami wirtualnymi.
  • reguły koligacji lub powinowactwa między grupami maszyn wirtualnych i grupami hostów ESXi.

Przyjrzyjmy się, jak te reguły działają na przykładach.

1. Załóżmy, że masz serwer bazy danych działający na jednej maszynie wirtualnej, serwer internetowy działający na drugiej maszynie wirtualnej i serwer aplikacji działający na trzeciej maszynie wirtualnej. Ponieważ te serwery współdziałają ze sobą, trzy maszyny wirtualne najlepiej byłoby przechowywać razem na jednym hoście ESXi, aby zapobiec przeciążeniu sieci. W tym przypadku wybieramy opcję “Zachowaj wirtualne maszyny razem” (powinowactwo).

2. Jeśli masz klaster na poziomie aplikacji wdrożony w maszynach wirtualnych w klastrze DRS, konieczne może być zapewnienie odpowiedniego poziomu nadmiarowości dla klastra na poziomie aplikacji (zapewnia to dodatkową dostępność). W takim przypadku możesz utworzyć regułę zapobiegającą koligacji i wybrać opcję “Oddzielne maszyny wirtualne”. Podobnie, możesz zastosować to rozwiązanie, gdy jedna maszyna wirtualna jest głównym kontrolerem domeny, a druga jest repliką tego kontrolera domeny (replikacja poziomu usługi Active Directory jest używana dla kontrolerów domeny). Jeśli host ESXi z główną maszyną wirtualną przestanie działać, użytkownicy mogą łączyć się z replikowaną maszyną VM kontrolera domeny, o ile ta ostatnia działa na osobnym hoście ESXi.

3. Reguła powinowactwa między maszyną wirtualną a hostem ESXi może być ustawiona z powodów licencyjnych. Jak wiesz, w klastrze VMware DRS maszyny wirtualne mogą migrować między hostami. Wiele zasad licencjonowania oprogramowania – na przykład oprogramowanie baz danych – wymaga od Ciebie zakupu licencji dla wszystkich hostów, na których działa oprogramowanie, nawet jeśli w klastrze jest tylko jedna maszyna wirtualna z oprogramowaniem. Dlatego należy uniemożliwić migrację takich maszyn wirtualnych do różnych hostów i naliczanie dodatkowych licencji. Możesz to osiągnąć, stosując regułę powinowactwa: maszyna wirtualna z oprogramowaniem bazy danych musi działać tylko na wybranym hoście, dla którego masz licencję. W takim przypadku wybierz opcję “Maszyny wirtualne na hosty”. Wybierz opcję “Uruchom na hoście”, a następnie wprowadź host z licencją. (Można również wybrać opcję “Nie należy uruchamiać na hostach w grupie” i określić wszystkie hosty nielicencjonowane).

Możesz zobaczyć, jak ustawić reguły koligacji w sekcji konfiguracji poniżej.

Wymagania dotyczące utworzenia klastra DRS

Aby skonfigurować klaster DRS, należy spełnić następujące wymagania:

  • Zgodność z procesorem. Wymagana jest maksymalna kompatybilność procesorów między hostami ESXi. Procesory muszą być produkowane przez tego samego sprzedawcę i należeć do tej samej rodziny z równoważnymi zestawami instrukcji. Najlepiej byłoby, gdyby ten sam model procesora był używany dla wszystkich hostów ESXi.
  • Udostępniony magazyn danych. Wszystkie hosty ESXi muszą być podłączone do współużytkowanej pamięci masowej, takiej jak SAN (Storage Area Network) lub NAS (Network Attached Storage), która może uzyskać dostęp do współużytkowanych woluminów VMFS.
  • Połączenie internetowe. Wszystkie hosty ESXi muszą być ze sobą połączone. Idealnie byłoby mieć oddzielną sieć vMotion, z co najmniej 1 Gbg przepustowości, do migracji VM między hostami.
  • Serwer vCenter musi być wdrożony w celu zarządzania i konfigurowania klastra.

Co najmniej 2 serwery ESXi muszą być zainstalowane i skonfigurowane (zalecane są 3 lub więcej serwerów ESXi).

Jak skonfigurować klaster DRS

Najpierw należy skonfigurować hosty ESXi, połączenie sieciowe, współużytkowaną pamięć masową i serwer vCenter. Po ich skonfigurowaniu możesz skonfigurować swój klaster DRS. Zaloguj się do serwera vCenter za pomocą klienta WWW vSphere. Utwórz centrum danych, w którym będą umieszczane hosty ESXi: vCenter -> Datacenter -> New Datacenter. Następnie wybierz centrum danych i kliknij opcję Działania -> Dodaj host, aby dodać hosty ESXi, których potrzebujesz, zgodnie z zaleceniami kreatora. Teraz jesteś gotowy do utworzenia klastra.

Aby utworzyć klaster, wykonaj następujące czynności:

  • Przejdź do vCenter -> Hosty i klastry.
  • Kliknij prawym przyciskiem myszy centrum danych i wybierz “Nowy klaster”.
  • Ustaw nazwę klastra i zaznacz pole “Włącz DRS”. Kliknij “OK”, aby zakończyć.

Jeśli masz już utworzony klaster, wykonaj następujące kroki:

  • Przejdź do vCenter -> Clusters -> Twoja nazwa klastra.
  • Otwórz Zarządzaj -> zakładka Ustawienia.
  • Wybierz “vSphere DRS” i kliknij “Edytuj”.
  • Zaznacz pole oznaczone “Turn ON vSphere DRS”. Kliknij “OK”, aby zakończyć.

Po utworzeniu klastra DRS można skonfigurować automatyzację DRS, DPM, reguły koligacji i inne opcje.

Automatyzacja DRS. Aby ustawić równoważenie obciążenia, potrzebujesz sekcji “Automatyzacja DRS”. Tutaj można wybrać poziom automatyzacji (ręczny, częściowo zautomatyzowany lub w pełni zautomatyzowany), a także próg migracji (wartości od 1 do 5, przy czym 1 oznacza konserwatywny, a 5 jest agresywny). Jeśli chcesz ustawić indywidualne poziomy automatyzacji maszyny wirtualnej, zaznacz odpowiednie pole.

Zarządzanie energią. Możesz ustawić DPM, wybierając jedną z następujących wartości: Off, Manual lub Automatic. Podobnie jak w przypadku funkcji równoważenia obciążenia opisanej powyżej, można wybrać wartości progowe DPM od 1 (konserwatywny) do 5 (agresywny).

Zaawansowane opcje. Możesz ręcznie ustawić zaawansowane opcje szczegółowego strojenia swojego klastra.

Na przykład możesz ustawić “Min. Balans 40” w celu obliczania niewyważenia. Domyślną wartością jest 50, a 0 jest najbardziej agresywną. Możesz przeczytać więcej na ten temat i poznać wszystkie zaawansowane opcje w dokumentacji VMware.

Zasady powinowactwa. Aby ustawić zasady powinowactwa i anty-powinowactwa, wykonaj następujące kroki:

1. Przejdź do vCenter -> Clusters -> nazwa twojego klastra
2. Przejdź do Zarządzaj -> zakładka Ustawienia
3. Wybierz “Reguły DRS” i kliknij “Dodaj” Ustaw nazwę reguły
4. Wybierz typ reguły:

Zachowaj wirtualne maszyny razem (powinowactwo)
Oddzielne maszyny wirtualne (anty-powinowactwo)
Maszyny wirtualne do hostów (powinowactwo lub anty-powinowactwo)

5. Wybierz maszyny wirtualne dla dwóch pierwszych typów reguł lub grup maszyn wirtualnych, grup hostów i zasad dla trzeciego typu reguły
6. Kliknij “OK”, aby zakończyć.

Pule zasobów. Aby utworzyć pulę zasobów dla maszyn wirtualnych w klastrze, wykonaj następujące czynności:

  • Przejdź do vCenter -> Clusters -> Twoja nazwa klastra.
  • Kliknij Czynności -> Nowa pula zasobów.
  • Nadaj puli nazwę, a następnie określ limity i rezerwacje dla procesora, a także pamięci.
  • Po zakończeniu kliknij “OK”.

Teraz możesz dodać swoje maszyny wirtualne do puli zasobów. Oto, jak przeprowadzić migrację istniejącej maszyny wirtualnej do puli zasobów:

  • Idź do vCenter -> Maszyny wirtualne.
  • Wybierz swoją maszynę wirtualną.
  • Kliknij Czynności -> Migruj. Pojawi się okno kreatora.
  • Wybierz “Zmień host” w sekcji “Typ migracji” i kliknij “Dalej”.
  • Wybierz pulę zasobów w sekcji “Wybierz źródło docelowe” i kliknij “Dalej”.
  • W sekcji “Wybór opinii” kliknij “Zakończ”.

Po zakończeniu konfiguracji możesz sprawdzić stan nowo utworzonego klastra DRS. Po prostu przejdź do vCenter -> Klastry -> Twoja nazwa klastra i kliknij kartę “Podsumowanie”.

Zalety korzystania z DRS

Główną zaletą korzystania z klastra VMware DRS jest efektywne zarządzanie zasobami z równoważeniem obciążenia. Poprawia to jakość świadczonych usług, a jednocześnie umożliwia oszczędzanie energii (a tym samym pieniędzy) za pomocą programu DPM. Możesz kontrolować rozmieszczenie maszyn wirtualnych ręcznie lub automatycznie, co sprawia, że ​​obsługa i wsparcie są wygodniejsze.

Podsumowanie

Rozwiązanie klastra DRS jest częścią oprogramowania do wirtualizacji vSphere VMware i jest szczególnie przydatne w dużych środowiskach wirtualnych. Funkcje DRS, takie jak równoważenie obciążenia, zarządzanie energią i reguły koligacji, pomagają zoptymalizować wykorzystanie zasobów, a także wydajność klastra. Dzięki Distributed Power Management możesz zaoszczędzić na kosztach energii elektrycznej. Używanie DRS w połączeniu z HA zapewnia zrównoważony klaster VMware vSphere o wysokiej dostępności, który jest efektywnym i wydajnym rozwiązaniem dla każdej wirtualnej infrastruktury.

NAKIVO Backup & Replication to produkt przeznaczony do ochrony wirtualnych maszyn VMware oraz klastrów. Podczas dodawania centrum vCenter z klastrem do zasobów produktu wszystkie maszyny wirtualne klastra są również automatycznie dodawane. Jeśli klaster został wybrany do zadania tworzenia kopii zapasowej lub replikacji, wszystkie maszyny wirtualne takiego klastra są wybierane automatycznie, niezależnie od hosta ESXi, na którym się znajdują.

Wypróbuj funkcje związane z klastrem i inne funkcje oprogramowania NAKIVO Backup & Replication w swoim środowisku – pobierz pełną wersję darmowej wersji próbnej: https://www.nakivo.com/resources/download/trial-download/

Backup środowisk wirtualnych – taśma czy dysk?

W ostatnich latach coraz bardziej popularne stają się rozwiązania do zabezpieczania danych wykorzystujące dyski twarde jako lokalizacje docelowe dla backupu. W dzisiejszych zwirtualizowanych data center, backup dyskowy zapewnia szybkość, elastyczność i bezpieczeństwo, które pozwalają zachować przedsiębiorstwom elastyczność w zakresie ochrony wirtualnych systemów. Umożliwiło to znaczącą redukcję parametrów RTO jednocześnie zbliżając RPO do bieżących wersji danych.

Tradycyjne kopie bezpieczeństwa tworzone przez systemy starszego typu wykorzystują głównie nośniki taśmowe do przechowywania kopii danych. Jednak większość nowoczesnych rozwiązań pozwala na zapis danych zarówno na taśmach jak i na dyskach twardych.

Jakie są zalety korzystania z obu nośników? Pomimo wielu zalet zapisu kopii danych na dyskach twardych, taśmy wciąż oferują możliwości, które warto wziąć pod uwagę projektując systemy backupu dla nowoczesnego data center. W tym artykule rozważymy zalety tworzenia backupu na taśmy i dyski twarde.

Backup maszyn wirtualnych na taśmy

Porównując przypadki użycia backupu taśmowego w porównaniu do backupu dyskowego, taśma ma kilka zalet:

  • Niezwykle niska cena za gigabajt
  • Długoterminowe przechowywanie lub archiwizacja danych w nieskończonej skali
  • Mobilność danych bez połączenia sieciowego

Pomimo spadających cen za gigabajt przestrzeni na dyskach twardych, wciąż trudno konkurować z cenami dzisiejszych nośników taśmowych – w przypadku kaset LTO-7 cena jednego gigabajta to ok. 1 cent. To sprawia, że taśma dalej jest niezwykle opłacalnym rozwiązaniem w przypadku wymogu pamięci masowej o dużej gęstości zapisu danych w przypadku środowisk wielotera- i petabajtowych.

W przypadku długotrwałego przechowywania lub archiwizacji danych, drogie macierze dyskowe nie są wystarczająco praktyczne i skalowalne. Zazwyczaj jest to miejsce, w którym kopia zapasowa na taśmę góruje. Przede wszystkim taśmy są dużo trwalsze. Można je łatwo skatalogować, wysłać i/lub przechowywać przez dłuższy okres czasu, a następnie wykorzystać ponownie, jeśli okres retencji danych został osiągnięty.

Porównując skalowalność systemu taśmowego i dyskowego, napęd taśmowy jest w istocie nieskończenie skalowalny, ponieważ można po prostu kupić więcej taśm. Nie wymaga to rozszerzania woluminów RAID ani innej manipulacji zestawami danych, tak jak ma to miejsce w przypadku rozwiązań opartych na dyskach. Skalowanie systemu lub macierzy dyskowej do obecnego poziomu taśm jest znacznie trudniejszy i kosztowniejszy.

Taśma jako medium ma również dużą przewagę nad backupem dyskowym dla organizacji, które chcą przechowywać kopię backupu poza siedzibą, ale nie mają dodatkowej lokalizacji połączonej za pośrednictwem łącza WAN. Organizacje z bezpośrednim połączeniem pomiędzy lokalizacjami mogą replikować maszyny wirtualne lub wysyłać kopie backupu powstałego na rozwiązaniach dyskowych pomiędzy ośrodkami.

Jeśli jednak mają tylko jedną lokalizację z łącznością sieciową, tworzenie backupu/archiwizacji na taśmie pozwala fizycznie skopiować backup poza miejsce instalacji w celu odzyskania danych po awarii. Nawet przy połączeniu sieciowym pomiędzy lokalizacjami, migracja dużej ilości danych za pomocą taśmy pozwoli znacząco odciążyć łącza obu lokalizacji.

Z punktu widzenia bezpieczeństwa, łatwość przenoszenia taśm z kopiami danych do innej lokalizacji może stanowić słaby punkt systemu. Osoba atakująca lub złośliwy pracownik może łatwo odejść z taśmami zawierającymi wrażliwe kopie zapasowe. W przypadku kopii zapasowych na dyskach nie jest to tak realne i łatwe do zrobienia.

Macierze dyskowe są zwykle znacznie bardziej monitorowane, a kradzież dysków twardych, szczególnie z aktywnej macierzy, jest zdecydowanie bardziej zauważalna niż kradzież taśm. Kradzież danych z macierzy wymagałaby skopiowania danych na inny nośnik pamięci, co wymaga czasu. Kradzież taśmy umożliwi szybki i natychmiastowy dostęp do danych w niej zawartych.

We współczesnym świecie dysków i magazynowania w chmurze, backup maszyny wirtualnej na taśmę nadal odgrywa znaczącą rolę w obecnych systemach ochrony danych. Backup maszyn wirtualnych oparty o taśmy zapewnia niskobudżetową, skalowalną i wysoce mobilną architekturę długoterminowego składowania danych, która uzupełnia możliwości systemów dyskowych zapewaniających przechowywanie danych krótko- i średnioterminowo.

Gdzie backup oparty na dyskach mieści się w dzisiejszym krajobrazie rozwiązań ochrony danych i jakie przypadki użycia są zadowalające w przypadku tworzenia kopii zapasowych maszyny wirtualnej na dysku?

Backup maszyn wirtualnych na dyski

Backup dyskowy odgrywa kluczową rolę w nowoczesnych rozwiązaniach ochrony danych. Ma wiele silnych stron, w tym:

  • Szybkie tworzenie kopii zapasowych i przywracanie
  • Łatwa mobilność danych
  • Bezpieczne kopie zapasowe
  • Wydajne medium do codziennych i cotygodniowych kopii zapasowych

Jednym z najważniejszych aspektów ochrony danych jest możliwość szybkiego tworzenia kopii zapasowych i odzyskiwania plików, aplikacji lub całych maszyn wirtualnych. To jest właśnie mocna strona backupu dyskowego.

Backup oparty o dyski twarde realizowany jest na macierzach dyskowych, które w przeciwieństwie do taśm nie wymagają ładowania/zmiany dysków, dyski i ich zawartość są stale dostępne. Dzisiejsze potężne macierze dyskowe, wsparte nowoczesną infrastrukturą sieciową, zapewniają ogromną przepustowość, która pozwala na szybkie kopiowanie danych z systemów produkcyjnych do pamięci dyskowej.

Dzięki ochronie danych za pomocą backupu dyskowego, mogą być one bardzo mobilne, łatwo kopiowane za pośrednictwem sieci do lokalizacji poza siedzibą, a nawet do chmury. Nie wymaga to ładowania fizycznych nośników lub transportu do innej lokalizacji. Backup dyskowy umożliwia łatwe kopiowanie danych backupu do innych lokalizacji, jednak wymaga to połączenia lokalizacji.

Obejmuje to infrastrukturę sieci LAN / WAN łączącą systemy backupu z siecią, a także łączność między lokacjami.

Backup dyskowy zapewnia również większe bezpieczeństwo danych niż taśmy. Fizyczny dostęp do dysków twardych umieszczonych w macierzy jest trudniejszy niż uzyskanie dostępu do taśm w bibliotece. Dyski w macierzy są ściśle monitorowane. Co więcej, dane zawarte w kopiach zapasowych na dyskach są zwykle rozmieszczone na wielu dyskach w tak zwanej nadmiarowej macierzy niezależnych dysków (systemy RAID). Kompletny zestaw danych wymaganych do rekonstrukcji maszyny wirtualnej lub wielu maszyn wirtualnych może być rozłożony na wiele dysków twardych w grupie RAID.

W przeciwieństwie do tego dane na taśmach zapisywane są sekwencyjnie. W ten sposób na pojedynczej taśmie może być zapisany pełny backup maszyny wirtualnej lub całego środowiska co w razie jej kradzieży daje dostęp do wszystkich danych. Sytuacja nie ma miejsca w przypadku dysków twardych, gdyż potrzebne byłyby wszystkie dyski z danej grupy RAID. W odniesieniu do fizycznego bezpieczeństwa danych, oznacza to zdecydowaną przewagę backupu dyskowego.

Typowym scenariuszem, gdzie wybierany jest backup dyskowy jest sytuacja tworzenia codziennych kopii bezpieczeństwa, których okres przechowywania wynosi do 90 dni. Kopie zapasowe oparte na dyskach zapewniają łatwość dostępu, wydajność, bezpieczeństwo i mobilność danych, których dzisiaj organizacje poszukują, chroniąc aplikacje o znaczeniu krytycznym. Wyobraź sobie, że musisz przywrócić pojedynczy plik usunięty przez użytkownika końcowego tydzień temu.

Wyciągnięcie zestawu taśm, załadowanie biblioteki i inwentaryzowanie taśm byłoby niewydajne. Dzięki kopii zapasowej na dysku, ten typ operacji może zostać wykonany w ciągu kilku minut, jeśli nie mniej!

Realia zabezpieczenia infrastruktury wirtualnej wymagają skutecznych i wydajnych systemów zapewniających bezpieczeństwo firmowych systemów o znaczeniu krytycznym. Stawia to szereg wyzwań związanych z wyborem sposobu przechowywania kopii bezpieczeństwa. Z jednej strony dyski twarde dają możliwość szybkiego i wygodnego tworzenia backupu oraz przywracania danych. Pozwalają też na łatwe zarządzanie danymi, ich mobilność oraz bezpieczeństwo.

Z drugiej strony mamy taśmy, które pomimo pozornych trudności w obsłudze i zarządzaniu dają nam wysoką skalowalność dostępnej przestrzeni w niskich kosztach i możliwość tworzenia rozbudowanych archiwów w innych lokalizacjach. Dlatego nie powinniśmy postrzegać dysków i taśm jako rozwiązań konkurencyjnych, a raczej jako komplementarne. Dyski dają nam łatwość dostępu dla backupu i danych niezbędnych do bieżących operacji firmy, z kolei taśmy rozszerzają możliwości o opcje długoterminowego archiwizowania ważnych informacji. W ten sposób zyskujemy wysoko funkcjonalne środowisko – opłacalne, wydajne, pozwalające na przechowywanie danych krótko- i długoterminowo.

Jak GDPR wpływa na ochronę danych

Nowy zestaw rozporządzeń wchodzi w życie w maju 2018 r., zwany GDPR lub ogólnym rozporządzeniem o ochronie danych. PKBR wpływa na wszystkie organizacje, które przetwarzają lub przechowują dane podmiotów z Unii Europejskiej. W ramach GDPR osoby, których dane dotyczą, mają całkowitą własność danych osobowych, w tym następujące postanowienia:

  • Prawo dostępu – Prawo dostępu do wszelkich danych osobowych przetwarzanych, przechowywanych itp.
  • Prawo do bycia zapomnianym – w ramach GDPR osoby fizyczne mają prawo zażądać usunięcia z procesora wszelkich danych zawierających, które ich dotyczą
  • Prywatność z założenia – Rozporządzenie w sprawie GDPR nakazuje, aby systemy zostały zaprojektowane w taki sposób, aby zapewnić prywatność osób chronionych na podstawie nowych przepisów

Myśląc o projektowaniu rozwiązań ochrony danych w nadchodzących latach, krytyczne dla biznesu kopie bezpieczeństwa krytyczne dla GDPR mają kluczowe znaczenie. Programiści muszą teraz zastanowić się, jak łatwo można uzyskać lub usunąć określone dane na żądanie. Chociaż interpretacje zakresu nowych przepisów są bardzo zróżnicowane, nie ma wątpliwości, że dane zawarte w systemach opartych na dyskach i taśmach podlegają kontroli na mocy nowego prawodawstwa.

Systemy kopii zapasowych środowisk wirtualnych obejmują zarówno pamięć krótko- jak i długoterminową w celu zapewnienia skutecznych zasad przechowywania danych. Backup VM na taśmach zapewnia ekonomiczny, nieskończenie skalowalny, długoterminowy magazyn, który pozwala organizacjom na wdrożenie pamięci masowej poza miejscem pracy nawet bez połączenia z lokacją dodatkową. Mogą jednak występować problemy z niezawodnością i bezpieczeństwem podczas tworzenia kopii zapasowych na taśmach. Backup dyskowy VM jest podstawowym nośnikiem danych wykorzystywanym przez współczesne nowoczesne rozwiązania do ochrony danych.

Kopie zapasowe na dysku zapewniają szybkie operacje tworzenia kopii zapasowych i przywracania danych zmienionych w ciągu ostatnich 90 dni, a także bezpieczeństwo danych. Niektóre z dzisiejszych rozwiązań ochrony danych środowisk wirtualnych korzystają z obu rodzajów backupu maszyn wirtualnych: taśmowego i dyskowego. Wykorzystując oba rozwiązania, możesz zaprojektować skuteczne, wydajne i niedrogie rozwiązanie do przechowywania kopii zapasowych dla codziennych / tygodniowych oraz długoterminowych kopii zapasowych.

NAKIVO Backup & Replication to nowoczesne rozwiązanie do ochrony danych, które pomaga sprostać wymagającym zadaniom RPO, RTO i regułom przechowywania danych. Produkt posiada wbudowaną kompresję, deduplikację, tworzenie backupu lokalnie i do lokalizacji zdalnych a także łatwą replikację maszyn wirtualnych do środowisk Disaster Recovery.

Tak więc, NAKIVO Backup & Replication może pomóc ci spełnić obecne i przyszłe wymagania w zakresie ochrony danych, w tym wymagania wprowadzone wraz z GDPR.

Szukasz pomocy w doborze sprawdzonego u ekonomicznego systemu kopii zapasowych? Zapraszam do kontaktu na adres storage@fen.pl

11 funkcji najnowszej wersji NAKIVO v7.4, które ułatwiają konfigurację kopii zapasowej

Nadchodząca wersja NAKIVO Backup & Replication v7.4 zawiera nowe funkcje usprawniające odzyskiwanie danych, zwiększające niezawodność i upraszczające zarządzanie ochroną danych.

1. Odzyskiwanie plików do źródła

Ważne pliki są często zagubione, uszkodzone lub przypadkowo usunięte. NAKIVO Backup & Replication pozwala odzyskać pliki bezpośrednio z deduplikowanych kopii zapasowych VM, bez konieczności przywracania całej maszyny wirtualnej. Począwszy od NAKIVO Backup & Replication v7.4, możesz przywrócić pliki do ich oryginalnej lokalizacji lub wybrać niestandardową.

2. Automatyczny VM failover z mapowaniem sieciowym i Re-IP

Każda sekunda jest cenna, gdy ważne maszyny wirtualne są wyłączone. Dlatego NAKIVO Backup & Replication v7.4 wprowadza nową funkcję – zadania VM Failover. Jeśli dojdzie do katastrofy, możesz przełączyć się na repliki VM w ciągu kilku minut.

Reguły mapowania sieciowego i Re-IP, które są częścią zadań VM Failover, skracają czas potrzebny na odzyskiwanie danych po awarii. Dzięki regułom mapowania sieciowego NAKIVO Backup & Replication może łączyć repliki VM z odpowiednimi sieciami w witrynie DR. Korzystając z reguł Re-IP, produkt może przypisać odpowiednie adresy IP do replik VM po przełączeniu awaryjnym.

3. Ulepszona kopia zapasowa AWS EC2

NAKIVO Backup & Replication v7.4 może tworzyć kopie zapasowe instancji AWS EC2 i zaoszczędzić nawet 1000 punktów odzyskiwania w celu elastycznego odzyskiwania. Dzięki nowej wersji możesz chronić swoje instancje EC2 i przechowywać kopie zapasowe w siedzibie firmy, aby zapewnić wyższą niezawodność. Aby dowiedzieć się, dlaczego kopie zapasowe są lepsze dla ochrony danych niż migawki AWS, pobierz bezpłatnie white paper.

4. Automatyczny Self-Backup

NAKIVO Backup & Replication v7.4 może wykonać kopię zapasową raz dziennie. Dzięki funkcji Self-Backup przywracanie wszystkich ustawień, obiektów magazynowych i harmonogramów zadań w nowej instancji jest tak proste, jak odzyskiwanie z najnowszej kopii zapasowej systemu.

5. Bandwidth Throttling

Oprogramowanie NAKIVO Backup & Replication zostało zaprojektowane tak, aby było szybkie i przesyłało dane z maksymalną dostępną prędkością. Jeśli jednak Twoje sieci są już mocno obciążone podczas tworzenia kopii zapasowej lub replikacji maszyny wirtualnej, możesz ograniczyć szybkość transferu danych.

Tutaj może pomóc nowa funkcja ograniczania przepustowości. NAKIVO Backup & Replication v7.4 umożliwia ustawienie ograniczeń prędkości dla swoich zadań. W ten sposób można na przykład ograniczyć zadanie kopii zapasowej do zużycia nie więcej niż 50 MB/s.

6. Wyszukiwanie globalne

Stosowanie kopii zapasowych maszyn wirtualnych, replik lub innych obiektów w infrastrukturze kopii zapasowych jest stosunkowo łatwe, gdy jest ich tylko kilka. Jednak Twoja infrastruktura staje się o wiele bardziej skomplikowana. Aby uprościć proces, NAKIVO Backup & Replication v7.4 zawiera funkcję globalnego wyszukiwania.

Możesz łatwo znaleźć kopie zapasowe VM, repliki, zadania, repozytoria i transportery, przeszukując całą infrastrukturę tworzenia kopii zapasowych. Możesz nawet uruchamiać zadania dla tych przedmiotów bezpośrednio ze strony wyników wyszukiwania.

7. Natychmiastowe odzyskiwanie VM dla Hyper-V

Funkcja Flash VM Boot w NAKIVO Backup & Replication v7.4 może natychmiast uruchomić maszyny wirtualne Hyper-V bezpośrednio ze skompresowanych i deduplikowanych kopii zapasowych.

Nie ma potrzeby, aby najpierw odzyskać całą maszynę wirtualną lub wykonać jakąkolwiek konfigurację specjalną. Flash VM Boot działa natychmiast „po wyjęciu z pudełka”: wystarczy wybrać kopię zapasową maszyny wirtualnej, punkt przywracania i lokalizację odzyskiwania, a następnie nacisnąć przycisk – maszyna wirtualna zostanie natychmiast uruchomiona.

8. Screenshot Verification dla maszyn wirtualnych Hyper-V

Tworzenie kopii zapasowej lub repliki maszyny wirtualnej Hyper-V niekoniecznie gwarantuje, że w razie potrzeby będzie możliwość odzyskania danych; kopia zapasowa lub replika może okazać się uszkodzona lub nie będzie można jej uruchomić. NAKIVO Backup & Replication v7.4 zapewnia zautomatyzowany sposób weryfikacji kopii zapasowych i replik VM Hyper-V w ciągu kilku minut.

Zaraz po zakończeniu zadania kopii zapasowej maszyny wirtualnej produkt może natychmiast odzyskać maszynę wirtualną Hyper-V z kopii zapasowej, poczekać na uruchomienie systemu operacyjnego, zrobić zrzut ekranu systemu operacyjnego, a następnie odrzucić odzyskaną maszynę wirtualną i wysłać wiadomość e-mail z załączonym zrzutem ekranu. Wszystko to odbywa się automatycznie i nie wymaga nadzoru.

9. Obcinanie dzienników dla Microsoft SQL Server 2017

Aby zapewnić niezawodność i umożliwić odzyskiwanie danych, program Microsoft SQL Server rejestruje wszystkie zmiany w bazie danych w plikach dziennika transakcji. Te pliki dziennika rosną w czasie i mogą zużywać całą dostępną przestrzeń dyskową, powodując awarię serwera. Funkcja skracania dziennika może automatycznie usuwać pliki dziennika ze źródłowej maszyny wirtualnej po pomyślnym utworzeniu kopii zapasowej lub replikacji w celu zwolnienia miejsca i zapewnienia nieprzerwanego działania serwera.

10. Natychmiastowy Object Recovery dla Microsoft SQL Server 2017

Microsoft SQL obsługuje wiele aplikacji o znaczeniu krytycznym dla biznesu; w związku z tym, jeśli baza danych SQL zostanie uszkodzona lub jeśli niepożądane zmiany zostaną wycofane, czas odzyskiwania powinien być jak najkrótszy. Funkcja Object Recovery dla Microsoft SQL Server zapewnia natychmiastowe odtwarzanie obiektów Microsoft SQL (baz danych i tabel) w ich pierwotnej lokalizacji lub niestandardowej.

11. Wbudowany czat z pomocą techniczną

Uzyskanie pomocy dotyczącej NAKIVO Backup & Replication v7.4 jest łatwiejsze niż kiedykolwiek wcześniej, ponieważ nowa wersja zapewnia zintegrowany czat z pomocą techniczną.

Czy jesteś podekscytowany nową gamą możliwości ochrony i odzyskiwania VM?

Zarejestruj się w NAKIVO Backup & Replication v7.4 Beta na stronie https://www.nakivo.com/resources/releases/v7.4/.

Czy chcesz teraz zacząć korzystać ze wszystkich podstawowych funkcji NAKIVO Backup & Replication? Pobierz pełną wersję darmowej wersji próbnej.

Nowe modele najpopularniejszych serwerów NAS dla firmy – TS-253Be i TS-453Be

Umarł król, niech żyje król! Jednym z najpopularniejszych modeli kierowanych do małych i średnich przedsiębiorstw, które potrzebowały małych, dwu- i czterodyskowych urządzeń były QNAPy z serii TS-x53A, czyli odpowiednio modele TS-253A oraz TS-453A. Producent oficjalnie zaprezentował ich następców, czyli TS-253Be i TS-453Be.

Te dwa modele cieszyły się dużym zainteresowaniem z kilku powodów. Przede wszystkim w atrakcyjnej cenie oferowały niezłą wydajność oraz obsługę wszystkich funkcji dostępnych w systemie QTS, w tym wirtualizacji. Model ten miał dużo portów, m.in. 2 porty HDMI pozwalające na podłączenie 2 ekranów zewnętrznych w rozdzielczości do 4K 2160P 30Hz Ultra HD czy wyjście audio.

Dodatkowo model czterodyskowy, czyli TS-453a posiadał duży wyświetlacz LCD informujący o statusie urządzenia.

Oczywiście jedną z najbardziej rzucających się w oczy rzeczy w budowie tego QNAP’a były dwa spore otwory z tyłu – były to gniazda line-in na dwa mikrofony, które można było wykorzystać z aplikacją OceanKTV Station, czyli aplikacją do… Karaoke. Sama opcja była na naszym rodzimym rynku mało popularna, ale warto wiedzieć. Ot, ciekawostka.

Samo urządzenie przez dłuższy czas dzielnie radziło sobie na rynku, jednak producent podjął decyzję o zakończeniu jego produkcji.

Wróćmy więc do tytułu. Produkcja modelu została zakończona, jednak producent zaproponował jego zastępstwo – serię TS-x53Be. Warto tutaj wyjaśnić kwestię nazewnictwa. Ogólnie w nazwach modeli QNAP dwie ostatnie cyfry oznaczają serię. Im wyższy numer, tym wyższa seria, a co za tym idzie, mocniejsze urządzenia.

Przykładowo mamy serie TS-x28a, TS-x51+, TS-x53Be czy TVS-x77. „X” z kolei oznacza liczbę zatok. Tak więc w serii TS-x53Be mamy modele z „2” i „4”, czyli dwu- i czterozatokowe urządzenia. Oczywiście w ramach danej serii, wszystkie urządzenia, bez względu na liczbę zatok mają taką samą lub bardzo zbliżoną specyfikację sprzętową (różnica to np. liczba interfejsów sieciowych).

TS-253Be, TS-453Be

Nowa seria to przede wszystkim odświeżony wygląd. Wcześniejsze metalowe obudowy zostały zastąpione plastikowymi. Może to u części użytkowników budzić wątpliwości co do trwałości, jednak materiały użyte do jej wykonania są dobrej jakości, plastik jest stosunkowo gruby, nie skrzypi, nie trzeszczy i jest dobrze dopasowany. Dlatego pod kątem wykonania nie ma się do czego przyczepić.

Dodatkową zmianą jest też rezygnacja z metalowych tacek na dyski – podobnie jak obudowa są plastikowe, jednak i tutaj nie ma zastrzeżeń co do jakości i wykonania. Plusem jest też system szybkiego montażu dysków – nie potrzebujemy do tego narzędzi, gdyż tacki są wyposażone w plastikowe blokady do dysków. Podsumowując – pod kątem budowy i wykonania urządzenie wypada bardzo dobrze, szczególnie, gdy musi stać na biurku lub w innym widocznym miejscu.

Kolejna zmiana pomiędzy starszą a nową serią to procesor. Modele TS-x53A wykorzystywały czterordzeniowe procesory Intel Celeron N3150 @ 1.60GHz, z kolei seria TS-x53Be jest już wyposażona w Intel Celeron J3455 @ 1.50GHz. Oczywiście na pierwszy rzut oka widać, że nowy model ma procesor o niższym taktowaniu, jednak nie powinno to nikogo zmylić, bo są one dużo wydajniejsze (porównanie można zobaczyć np. tutaj: https://www.cpubenchmark.net/compare.php?cmp[]=2875&cmp[]=2546)

Model dodatkowo obsługuje szyfrowanie Intel AES-NI z akceleracją sprzętową, dzięki czemu przy 256-bitowemu szyfrowaniu woluminów lub folderów, transfer mogą dochodzić nawet do 225MB/s. Dla porównania, w przypadku braku szyfrowania, transfery osiągają takie same wartości, a więc nie ma obaw, że zwiększenie bezpieczeństwa przechowywanych danych będzie wiązało się z utratą wydajności.

Testy przeprowadzono w laboratoriach QNAP. Wyniki mogą się różnić w zależności od środowiska.

Środowisko testowe:

NAS:
System operacyjny: QTS 4.3.3
Wolumin: RAID 5; 4 dyski SSD Intel S3500 240 GB (SSDSC2BB240G4); 2 porty QNAP LAN-10G2SF-MLX 10GbE SFP+

Komputer kliencki:
Procesor Intel® Core™ i7-4770 3,40 GHz; pamięć DDR3L 1600 Hz 16 GB; WD 1TB WD10EZEX; Intel Gigabit CT (MTU 1500); Windows® 10 64-bitowy

Kolejna zmiana to wielkość pamięci RAM – wcześniej modele występowały w wersjach 4GB i 8GB, teraz mamy 2GB lub 4GB. Oczywiście wciąż można RAM rozszerzyć, i tutaj zmian nie ma, maksymalna ilość to 8GB, przy czym modele serii Be obsługują już pamięci taktowane 1866 MHz.

I czas na największą zmianę – seria Be wyposażona jest w port PCIe. Pozwala to na znaczne powiększenie funkcjonalności urządzenia, ponieważ mamy możliwość montażu kart rozszerzeń. Pełna lista obsługiwanych jest tutaj: https://www.qnap.com/pl-pl/compatibility/?model=312&category=11

Warto zauważyć, że w ten sposób możemy podłączyć do naszego QNAPa kartę obsługującą interfejsy sieciowe 10GbE (RJ-45 lub SFP+) oraz kartę QM.2, która pozwala dodać 2 dyski M.2, a tym samym dwudyskowe urządzenie zmienić na czterodyskowe. W ten sposób możemy skorzystać z opcji SSD caching lub Qtier, a więc automatycznego pozycjonowania danych na dyskach.

Karty QM.2 występują w 4 wersjach:

  • QM2-2S, obsługująca do 2 dysków M.2 SATA 2280
  • QM2-2P, obsługująca do 2 dysków M.2 PCIe NVMe 22110 lub 2280
  • QM2-2S10G1T, obsługująca do 2 dysków M.2 SATA 2280 oraz wyposażona w jeden port 10GbE Base-T,
  • QM2-2P10G1T, obsługująca do 2 dysków M.2 PCIe NVMe 22110 lub 2280 oraz wyposażona w jeden port 10GbE Base-T.

Nowe modele oferują też 5 portów USB 3.0, w tym jeden z przodu obudowy, pozwalający na skonfigurowanie opcji szybkiego kopiowania danych pomiędzy pamięcią USB a QNAP’em. Podobnie jak poprzednik, seria TS-x53Be posiada 2 porty HDMI obsługujące rozdzielczość do 4K oraz 3 porty audio, 1 line-out oraz 2 wejściowe (na mikrofony), przy czym wszystkie są już w wersji mini jack 3,5 mm.

Warto tutaj nadmienić, że producent kładzie duży nacisk na rozwój funkcji multimedialnych urządzenia, zarówno pod kątem liczby portów wejścia/wyjścia, ale też rozwijając aplikacje do zarządzania i odtwarzania multimediów. Idealnym przykładem jest aplikacja Cinema28, która pozwala z poziomu systemu QTS odtwarzać multimedia na zewnętrznych odbiornikach przez AirPlay czy DLNA, ale też kierować strumień do odbiorników podłączonych właśnie przez HDMI czy audio-out.

Przy opisie urządzenia nie sposób oczywiście napisać o jednej z najważniejszych funkcji, czyli mechanizmie wykonywania migawek. Migawki pomagają chronić dane poprzez rejestrację stanu i metadanych systemu NAS. W momencie wykonywania migawki system rejestruje, które bloki są wykorzystywane, a które nie, chroniąc te zapisane przed edycją.

W przypadku przypadkowej modyfikacji czy usunięcia pliku, możliwe jest jego przywrócenie z migawki (wersja pliku będzie dokładnie taka, jak w momencie tworzenia migawki). Migawki mogą obejmować całe woluminy, pojedyncze udziały sieciowe oraz jednostki LUN.

Daje to wysoki poziom bezpieczeństwa dla danych, chroniąc również przed zagrożeniami typu ransomware – nawet w przypadku zaszyfrowania danych na udostępnionym zasobie istnieje możliwość ich przywrócenia z migawki utworzonej wcześniej, przed infekcją.

Seria TS-x53Be to wydajne urządzenia w dobrej cenie, które warto stosować wszędzie tam, gdzie nie ma potrzeby lub możliwości stosowania urządzeń RACK, a jednocześnie potrzebne jest małe i wydajne rozwiązanie. Warto też pamiętać, że modele TS-253Be i TS-453Be to bardziej budżetowe wersje modeli z serii TS-x53B, która obejmuje też urządzenia z sześcioma zatokami na dyski twarde oraz dostępna jest w konfiguracji z 4GB lub 8GB RAM.

Urządzenia z literką „B” posiadają też porty USB-C QuickAccess, slot na kartę pamięci SD, przez co mogą być atrakcyjne np. dla fotografów czy osób zajmujących się nagrywaniem video, pilot zdalnego sterowania (RM-IR004) oraz mały wyświetlacz OLED prezentujący najważniejsze komunikaty systemu. Jeśli jednak te dodatkowe opcje nie są niezbędne, seria TS-x53Be powinna w zupełności wystarczyć.

6 funkcji NAKIVO, które zachwyciły użytkowników VMware na konferencji VMUG 2018

NAKIVO jest rozwiązaniem do backupu maszyn wirtualnych działających w środowiskach VMware, Hyper-V oraz Amazon EC2. Podczas konferencji Poland VMUG UserCon 2018 w Warszawie mieliśmy okazję zaprezentować NAKIVO zainstalowane na QNAP, a więc atrakcyjne cenowo (i funkcjonalnie!) rozwiązanie backup appliance.

Nasz zestaw wzbudził niemałe zainteresowanie. Zobaczmy więc, które funkcje były dla uczestników najciekawsze.

1. Instalacja na QNAP

Większość odwiedzających stanowisko NAKIVO nie zwracała w pierwszej chwili uwagi na to, jak Nakivo jest zainstalowane – wszyscy zakładali, że zainstalowaliśmy je wewnątrz którejś z maszyn wirtualnych.

Dopiero po krótkiej rozmowie, gdy okazywało się, że NAKIVO działa jako natywna aplikacja w QNAP, zainteresowanie rosło. Dlaczego?

NAKIVO nie wymaga dedykowanej platformy sprzętowej lub systemowej do instalacji. Tak naprawdę możemy utworzyć serwer backupu na dowolnej maszynie z systemem Linux lub Windows, ale także zainstalować aplikację na NAS QNAP, które rozwiązanie szczególnie polecamy.

My pokazaliśmy połączenie NAKIVO x QNAP TVS-882-i5-16G. Takie połączenie daje nam sporo możliwości – cały proces backupu, kompresji, deduplikacji obciąża tylko naszego NAS’a, a nie środowisko produkcyjne. A dodatkowo zachowujemy całą funkcjonalność urządzenia – NAKIVO działa na QNAP równolegle z innymi aplikacjami czy usługami.

Więcej o instalacji NAKIVO na QNAP możesz poczytać w tym artykule (https://makeittogether.pl/konfiguracja-backupu-maszyn-wirtualnych-na-nakivo-qnap-i-vmware-exsi/)

2. Globalna deduplikacja

Deduplikacja pozwala na ograniczenie wielkości backupu poprzez wykluczanie z backupu bloków, które już w nim istnieją. W ten sposób możemy zminimalizować ilość danych przechowywanych w repozytorium, szczególnie wtedy, gdy backupujemy wiele maszyn wirtualnych o podobnej zawartości (np. utworzonych z jednego template).

NAKIVO Backup & Replication automatycznie wykorzystuje deduplikację podczas tworzenia każdego z backupów w ramach całego repozytorium backupu.

Oznacza to, że niezależnie do tego, czy backupujemy maszyny wirtualne z VMware, Hyper-V czy instancje AWS EC2, deduplikacja pozwoli wykluczyć powtarzające się bloki.

3. Flash VM Boot

Funkcja, która pozwala sprawdzić, czy maszyny zostały poprawnie zbackupowane, ale przede wszystkim daje możliwość Disaster Recovery – maszyna wirtualna może być uruchomiona na wskazanym serwerze ESXi bezpośrednio z backupu, z pominięciem procesu przywracania czy kopiowania plików.

Dzięki temu w ciągu zaledwie kilku minut wcześniej uszkodzony/utracony system może znowu pracować i udostępniać swoje funkcje dla użytkowników. Dodatkowo NAKIVO pozwala na późniejszą migrację takiej maszyny do środowiska produkcyjnego z pominięciem wykonywania dodatkowego backupu.

Uwaga – maszyna wirtualna w trybie Flash VM Boot jest uruchamiana z backupu skompresowanego i zdeduplikowanego, więc na potrzeby tej funkcji nie musimy tworzyć osobnych kopii bezpieczeństwa.

4. Screenshot Verification

Funkcja Flash VM Boot wykorzystywana jest też przez mechanizm Screenshot Verification.

Zwykle backup weryfikowany jest w najprostszy sposób, czyli za pośrednictwem sum kontrolnych. Ma to oczywiście swoje zalety, jednak nie sprawdza jednej istotnej kwestii, czyli działania samego systemu.

Jeśli np. system zostanie uszkodzony w wyniku problemów z systemem plików czy np. szyfrowania przez ransomware, backup może wykonać się poprawnie, sumy kontrolne będą się zgadzały, jednak dane/system będą uszkodzone.

NAKIVO postępuje inaczej. Po wykonaniu backupu maszyna jest uruchamiana we wskazanym środowisku, po czym odczekuje wskazany przez administratora czas (np. 3 minuty) i wykonuje zrzut ekranu w konsoli takiej maszyny.

Taki zrzut jest wysyłany później mailem do Administratora. W ten sposób administrator ma pewność, że w razie problemów, będzie w stanie przywrócić z backupu działający system.

Więcej o tej opcji możesz poczytać tutaj: https://www.nakivo.com/features/screenshot-verification/

5. Replikacja

Replikacja! Jak sama nazwa oprogramowania wskazuje (NAKIVO Backup&Replication), producent kładzie bardzo duży nacisk na możliwości replikacji danych.

Pierwsza opcja to oczywiście replikacja samego backupu (plików) do zewnętrznych repozytoriów (udział sieciowy off-site, drugi serwer backupu NAKIVO, ale też chmura AMAZON czy MS Azure).

Pozwala to ochronić pliki backupu na wypadek np. awarii storage w lokalizacji głównej.

Druga, znacznie ciekawsza opcja pozwala na zachowanie ciągłości działania. Jest to opcja replikacji maszyn wirtualnych do innych hypervisorów. W ten sposób możemy skonfigurować tworzenie kopii całych maszyn wirtualnych do osobnego środowiska lub do lokalizacji off-site.

Taka replika jest tworzona z pominięciem wykonywania backupy (osobne zadania), dzięki czemu nie wymaga dodatkowej przestrzeni dyskowej i jest wykonywana szybciej.

Replika zapisywana jest w datastore docelowego środowiska, dzięki czemu w razie potrzeby uruchomienia takiej maszyny wirtualnej, może ona działać już docelowo w tym środowisku.

Co ważne, w przypadku potrzeby uruchomienia maszyny, zachowujemy do 30 punktów przywracania, co oznacza, że nawet w przypadku zreplikowana uszkodzonej maszyny, możemy uruchomić jej wcześniejszą wersję.

6. Funkcje dostępne w cenie

NAKIVO ma bardzo prosty sposób licencjonowania, gdzie mamy dwie główne wersje – wersję PRO i wersję ENTERPRISE.

Różnica pomiędzy nimi jest niewielka – integracja z AD, API http czy opcje multi-tenancy. Oznacza to, że wszystkie powyższe opcje są dostępne zawsze w cenie rozwiązania. Nie musimy dokupować licencji na kolejne gigabajty danych czy możliwość granularnego przywracania danych czy zawartości MSQL czy MS Exchange.

Więcej o rodzajach dostępnych licencji i tym, co zawierają, możesz poczytać tutaj: https://www.nakivo.com/how-to-buy/vmware-hyper-v-pricing/

Oczywiście NAKIVO Backup & Replication posiada ogrom innych funkcji. Poznać je można na stronie producenta: https://www.nakivo.com/vmware-backup/

QNAP jako rejestrator monitoringu na Virtualization Station

Budując system monitoringu IP często stoimy przed wyborem kompromisu pomiędzy funkcjonalnością a jakością oraz przede wszystkim ceną nowego rozwiązania. Bardzo często zdarza się, że chcemy wykorzystać już zainstalowany sprzęt w nowym zastosowaniu, aby właśnie ograniczyć koszty.

Macierze Qnap dają szerokie spektrum możliwości poprzez wykorzystanie do monitoringu aplikacji Surveillance Station oraz QVR Pro (oraz również zarządzanie poprzez QVR Center oraz QVR Guard) ale co zrobić jeżeli dane modele kamer nie są kompatybilne bądź będziemy potrzebować dodatkowej funkcji kamery lub oprogramowania, która nie jest natywnie zintegrowana z aplikacjami QNAP.

QNAP oferuje jeszcze jedną możliwość: wykorzystanie nieużywanych zasobów sprzętowych macierzy do utworzenia maszyny wirtualnej z dedykowanym oprogramowaniem do monitoringu IP. Z pomocą przyjdzie nam aplikacja Virtualization Station.

Mamy dwie możliwości wykorzystania QNAP z Virtualization Station pod systemy MIP:

  1. Tworząc standardową architekturę typu klient -> serwer (obciążenie renderowania strumienia z kamer jest po stronie klienta instalowanego na stacji roboczej). Zasady podłączenia są identyczne jak w typowej konfiguracji monitoringów w architekturze klient -> serwer.
  2. Tworząc wewnętrzną architekturę typu klient -> serwer (wewnętrzną mam na myśli instalację w systemie operacyjnym na Virtualization Station zarówno oprogramowania serwera jak i oprogramowania klienta).

Pierwsza droga, czyli architektura klient -> serwer jest najpopularniejsza i bardzo często wykorzystywana (wariant zalecany) ale QNAP do większości dużych macierzy NAS (ze względu na możliwości można śmiało powiedzieć, że są to już serwery) daje możliwość instalacji zewnętrznej karty graficznej.  Nasuwa się jedno zasadnicze pytanie – po co? A właśnie po to, aby stworzyć pełnoprawny rejestrator z opcją wyświetlenia obrazu na wielu monitorach. Oczywiście jest to opcja, ale sprawdziłem jak teoria ma się do praktyki.

Całość brzmi skomplikowanie, nic bardziej mylnego! Cały proces składa się z kilku prostych kroków, które przedstawię opierając się na naszym LAB’owym QNAP TDS-1649U z zewnętrzną kartą graficzną (ASUS R7 240 2G) oraz oprogramowaniu DSS Pro z kilkoma podpiętymi kamerami znanego producenta kompleksowego systemu monitoringu – Dahua Technology.

Przy wyborze kart graficznych do modeli Qnapa, należy się posługiwać listą kompatybilności -> DOSTĘPNA TUTAJ

Kroki jakie wykonałem:

  1. Instalacja zewnętrznej karty graficznej w slocie PCIe x16
  1. Uruchomienie QNAP i instalacja aplikacji Virtualization Station
  1. Utworzenie maszyny wirtualnej w oparciu o system operacyjny (w moim przypadku Windows 10 Pro] oraz konfiguracja parametrów maszyny oraz wersję Klient , CBR 6Mbps, 20fps]
    3x Dahua HFW2431RP-ZE-IRE6 , CBR 6Mbps, 20fps]

    Platforma sprzętowa (Przydzielone zasoby z TDS-1649U)
    Windows 10 Pro (wersja testowa)
    Procesor – 14 wątków przydzielonych (z 26 dostępnych)
    RAM – 30GB (z 64GB dostępnych – specjalnie na wyrost, aby mieć zachowaną płynność)
    Przydzielona grafika – Radeon R7 240 2GB

Porównanie nagrań przy wykorzystaniu zewnętrznej karty graficznej i bez wykorzystania zewnętrznej karty graficznej.

Jak widać na powyższych nagraniach, test wykazał poprawność (płynność) działania kamer na oprogramowaniu DSS Pro (wersja Klient) na Virtualization Station przy wykorzystaniu zewnętrznej karty graficznej. Pracując na emulowanej grafice (wbudowanej w wirtualizator) nie da się płynnie wyświetlać obrazu z kamer (czy to przy wykorzystaniu DSS Pro czy też innego oprogramowania).

Obciążenie procesora oraz pamięci RAM „gościa” (parametry sczytane z systemu operacyjnego Windows 10) mieściło się w przedziale 50%-55% (przy generowaniu gwałtownych ruchów przed kamerami).

Obciążenie „hosta” (parametry sczytane z panelu Virtualization station) wynosiło odpowiednio dla procesora 32%-55% a dla pamięci RAM 44%-48%.

Qnap sprawdził się jako pełnoprawny rejestrator, wykorzystanie zewnętrznej karty graficznej daje spore możliwości i tym samym teoria została potwierdzona w praktyce.

Finalna wersja QNAP QVR Pro 1.0 – przegląd funkcji i licencjonowanie

26 stycznia pojawiła się w AppCenter Qnap finalna wersja aplikacji do monitoringu Qnap QVR Pro, oznaczona wersją 1.0. Poniżej kilka przemyśleń po pierwszym spojrzeniu na najnowsze wydanie aplikacji.

Aplikacja po pierwszych testach wydaje się działać bardzo stabilnie, zostało wyeliminowanych kilka niedociągnięć z wersji beta (m.in. brak możliwości zgrywania nagrań bezpośrednio z klienta – QVR Pro Client).

Wnioski po weekendowych testach:

Znany z wersji beta nowy layout jest bardzo przyjazny, można powiedzieć przystosowany do wymagań użytkowników w 2017/2018 roku (nie ma co ukrywać, dla użytkowników wygląd jest bardzo ważny).

Funkcja dodawania kamer po nazwie działa dużo lepiej (dużo łatwiejsze dodawanie urządzeń Dahua, które w Surveillance Station dodawane muszą być po pełnym symbolu – teraz wystarczy podanie jedynie członu nazwy). Udało się podpiąć Dahua HFW5231EP-Z12 po nazwie HFW5231E-Z. W Surveillance Station nie udało się tego zrobić – pojawia się błąd.

Dodanie kamery z powyższego punktu uruchomiło detekcję ruchu – działa bardzo przyjaźnie dla użytkownika poprzez migające obramowanie obrazu z kamery (na ten moment to już standard w nowoczesnych systemach MIP).

Dodawanie zdarzeń jest bardzo przyjazne i klarowne. Nie było problemów z nagrywaniem strumienia po wywołaniu zdarzenia (czyli po wykryciu ruchu) oraz z powiadomieniem mailowym po SMTP na Gmail (poniżej nagranie).

Klient na stacje robocze QVR Pro Client jest intuicyjny, można płynnie zmieniać widoki, działa e-mapa oraz co jest bardzo ważne importowanie nagrań bezpośrednio z klienta (nie było tej możliwości w wersji beta a jest to bardzo, bardzo wygodne).

Aplikacja mobilna QVR Pro Client również jest bardzo intuicyjna (poniżej nagranie). Można odtwarzać nagrania bezpośrednio z apki + widzieć np. e-mapy utworzone w kliencie na Windows.

Czyli podsumowując: duży plus w stosunku do przestarzałego Surveillance Station, który miał swoje lata.Licencjonowanie QVR Pro

Każde urządzenie, które obsłuży QVR Pro będzie miało 8 licencji za darmo.
Ważne – QVR Pro wymaga do działanie min. 4 GB RAM.

Urządzenia, które nie spełniają powyższego będą mogły dalej korzystać z Surveillance Station.

Surveillance Station dalej będzie dostępna, ponieważ będzie jedyną opcją dla modeli ARM i nieobsługujących więcej niż 2GB RAM.

Na chwilę obecną nie ma możliwości migrowania licencji między Surveillance Station a QVR Pro. Aplikacje traktowane są jako osobne rozwiązania.

Chcesz dowiedzieć się więcej? Zapraszamy do kontaktu na adres support@fen.pl.Aktualizacja 05.02.2018

Wielostrumieniowość – jak wykorzystać potencjał wielu strumieni w kamerze ?

W zeszłym tygodniu przedstawiłem testy nowo wypuszczonej aplikacji przez Qnapa do MIP – QVR Pro.

Dziś przedstawiam jak praktycznie wykorzystać ilość strumieni w kamerach IP, które są bardzo powszechnie promowane przez producentów kamer. Tego typu rozwiązanie stosuje się aby:

Jako przykład wykorzystam dla odmiany kamerę naszego stałego przyjaciela – ACTi E926M.

Kamera posiada wbudowaną obsługę dwóch strumieni, które Qnap z kolei zaimplementował w swoich aplikacjach do monitoringu IP.

W pierwszej kolejności przedstawiam nagranie pokazujące dodanie oraz ustawienie strumieni kamery:

Poniżej zaś przedstawiam efekt takich ustawień czyli zamierzone nagrywanie w lepszej jakości przy wykryciu ruchu oraz nagrywanie ciągłe aby nie utracić ważnych danych z kadru.

Jak z kolei wygląda zgrywanie późniejszych nagrań ? Poniżej przykład:

myQNAPcloud – wykorzystanie do MIP

Bardzo popularne narzędzie, które już zapewne większość z użytkowników Qnapa zna doskonale i korzystania na co dzień.

Warto również zaznaczyć, że możemy wykorzystać potencjał owej chmury do logowania się do aplikacji QVR Pro. Chcę od razu na wstępie zaznaczyć, że myQNAPcloud jak sama nazwa wskazuje to chmura DDNS, więc należy mieć u operatora odblokowaną możliwość przekierowania portów. Jest to konieczne, aby usługa zadziałała prawidłowo.

Ja osobiście w tym celu byłem zmuszony wykupić u mojego operatora dostęp do publicznego adresu IP .

Co tak naprawdę daje chmura myQNAP cloud ? Otóż w bardzo wygodny sposób umożliwia logowanie do naszego MIP bez potrzeby znajomości a tym bardziej pamiętania w jakiej sieci się znajdujemy .

Bez tej usługi logując się do QVR Pro musimy pamiętać jakiego adresu IP użyć .

Chmura myQNAPcloud od razu przypisuje adres IP sieci w jakiej się znajdujemy przez co nie ma potrzeby kontrolowania tego procesu.

Konfiguracja chmury ze strony Qnap -> instrukcja

Poniżej nagranie prezentujące jak w łatwy i przystępny sposób wygląda logowanie do aplikacji QVR Pro Client :

NAKIVO Backup & Replication v7.3 już dostępne!

Na początku listopada wydana została open beta NAKIVO Backup & Replication v7.3. Nie minął jeszcze miesiąc, a prężnie rozwijający się producent wypuścił pełną wersję swojego softu.

NAKIVO Backup & Replication v7.3 jest już gotowe do pobrania. Dodane zostało wsparcie dla zewnętrznych rozwiązań dedykowanych do deduplikacji, co tym samym wprowadza nowy rodzaj deduplikacji oraz możliwość stworzenia nowego rodzaju repozytorium oraz bezproblemową integrację oprogramowania z infrastrukturą, w której takie urządzenia już się znajdują.

Integracja ta osiągnięta jest właśnie przez nowy typ repozytorium backupu, które zostało zoptymalizowane do pracy na dedykowanych do deduplikacji rozwiązaniach. Dzięki temu NAKIVO Backup & Replication idealnie współpracuje z takimi rozwiązaniami jak Quantum DXi, NEC HYDRAstor, EMC Data Domain, HP StoreOnce, itp.

Testy w środowiskach klientów pokazały, że nowy typ repozytorium pozwolił NAKIVO Backup & Replication v7.3 na backup maszyn wirtualnych nawet, uwaga, 53 razy szybciej, niż w przypadku zwykłego repozytorium. Przy użyciu zaawansowanego rozwiązania do deduplikacji – NEC HYDRAstor – NAKIVO Backup & Replication osiągnęło prędkość wykonywania backupu na poziomie 3.2 GB/s!

Jak działa nowe repozytorium?

Główna różnica między normalnym (typu forever-incremental) a nowym repozytorium jest dość łatwa do wywnioskowania – normalne repozytorium przechowuje tylko przyrosty (np. zmiany wprowadzone do maszyny wirtualnej od ostatniego zadania backupu), a nowe repozytorium przechowuje całe łańcuchy backupu maszyny wirtualnej, które składają się z kilku pełnych backupów oraz kilku przyrostów pomiędzy kolejnymi pełnymi kopiami.

W kontekście integracji z rozwiązaniami do deduplikacji, nowe repozytorium:

  • Tworzy mniej strumieni danych w operacjach odczytu/zapisu podczas backupu oraz odzyskiwania maszyn wirtualnych
  • Nie wykorzystuje funkcji deduplikacji globalnej, którą znamy z NAKIVO Backup & Replication

Ale przyjrzyjmy się temu bliżej.

Mniej strumieni danych

Gdy do backupowania maszyny wirtualnej wykorzystywane jest normalne repozytorium, zmienione bloki danych są zapisywane do tysięcy różnych plików w tym samym czasie. Skutkuje to tysiącami jednoczesnych strumieni danych i rozrzuceniem bloków danych z jednej maszyny wirtualnej po całym repozytorium. Rozwiązania do deduplikacji klasy enterprise są zoptymalizowane do otrzymywania danych w ograniczonej ilości strumieni (bardziej nastu niż tysięcy).

W nowym typie repozytorium, wszystkie zbackupowane bloki są porządkowane w ograniczone ilości plików dla każdej maszyny wirtualnej – jeden pełny backup i jeden kolejny plik na każdy przyrost. Dzięki temu, gdy zadanie backupu jest uruchamiane, mamy do czynienia z jednym tylko strumieniem dla każdej maszyny wirtualnej.

Wyłączona deduplikacja software’owa

Wiemy, że NAKIVO Backup & Replication posiada świetną funkcję deduplikacji danych, która jest zaprojektowana tak, by zmniejszać rozmiar backupów naszych maszyn wirtualnych. Jednakże, jeśli w infrastrukturze działają duże serwery, które mają wbudowane funkcje deduplikacji, jak np. EMC Data Domain, HP StoreOnce, NEC HYDRAstor czy Quantum DXi, to ich deduplikacja może „rywalizować” z tą wbudowaną w NAKIVO. Może to mieć bardzo negatywny wpływ na wydajność całego procesu backupu.

Wybierając nowy typ repozytorium jednocześnie zmuszamy NAKIVO Backup & Replication do wyłączenia swojej wbudowanej deduplikacji. Pozwala to na unikanie konfliktów między dwoma konkurencyjnymi rozwiązaniami, które robią to samo, ale w inny sposób. Zatem, gdy w infrastrukturze znajduje się dedykowany appliance do deduplikacji, wybieramy nowe repozytorium i korzystamy z deduplikacji tego urządzenia, nie tej wbudowanej w NAKIVO.

Większa wiarygodność

Tworzenie okresowych pełnych backupów oznacza, że w przypadku odzyskiwania danych mamy zawsze niedawno zrobioną pełną kopię, z której możemy odzyskać nasze dane. Zwiększa to prędkość oraz wiarygodność odzyskiwania, ponieważ tylko kilka z naszych przyrostów musi być złączonych z backupem pełnym.

Łatwe zarządzanie plikami backupu

Z nowym typem repozytorium, zwolnienie miejsca na storage’u jest banalne – wystarczy wybrać pliki przyrostów lub pełnych backupów, które chcemy usunąć. Starsze pliki będą usuwane automatycznie, zgodnie z ustaloną polityką retencji.

Brak konieczności odzyskiwania przestrzeni

Kiedy backup maszyny wirtualnej zostaje usunięty, w normalnym repozytorium pojawiają się niezagospodarowane miejsca, gdzie wcześniej były składowane konkretne bloki danych.  Te miejsca nie zawsze mogą od razu zostać nadpisane przez nowe bloki danych, więc od czasu do czasu trzeba wykonywać „odzyskiwanie” tej przestrzeni (ang. space reclaim). W nowym repozytorium, z powodu innego podejścia do składowania plików, nie jest to konieczne.

Jak używać nowego typu repozytorium?

Jak używać nowego typu repozytorium na backup maszyn wirtualnych w NAKIVO Backup & Replication v7.3?

Aby zacząć używać nowego repozytorium, należy przejść następującą ścieżkę: Konfiguracja >> Repozytoria >> Dodaj Repozytorium >> Stwórz nowe repozytorium.

W polu Typ, wybierz „Incremental with full backups”, czyli przyrostowy z pełnymi backupami.

Pozostałe ustawienia mogą być konfigurowane tak samo jak zwykle, poza tym, że opcje deduplikacji oraz odzyskiwania przestrzeni nie będą dostępne.

Uwaga: jeśli zaznaczysz opcję „The target is the deduplication appliance”, automatycznie wybrany zostanie nowy typ repozytorium.

Podsumowanie

To, jaki typ repozytorium na backupu swoich maszyn wirtualnych w NAKIVO Backup & Replication v7.3 wybierzesz, powinno zależeć od konkretnych potrzeb twojej firmy. Każdy z typów ma swoje zalety, niemożliwym jest też wskazanie, że jedno jest lepsze od drugiego. Dostępność obu opcji daje ci wybór i elastyczność, dzięki której możesz zdecydować, które z rozwiązań będzie najlepiej działało w twoim środowisku. W odniesieniu do innych przydatnych funkcji NAKIVO Backup & Replication, oba typy repozytoriów dają równe możliwości i są równie wygodne dla użytkownika.

Pobierz NAKIVO Backup & Replication v7.3 z wsparciem dedykowanych rozwiązań do deduplikacji już teraz!

NAKIVO Backup & Replication v7.3 – BETA

Nakivo – amerykański producent rozwiązań do backupu środowisk wirtualnych na VMware, Hyper-V oraz instancji chmurowych Amazon Web Services EC2 – wypuścił wersję beta nowego oprogramowania NAKIVO Backup & Replication v7.3.

Nakivo po raz kolejny pokazuje, że bardzo poważnie traktuje rozwój swojego oprogramowania – zaledwie dwa miesiące temu pisaliśmy o premierze NAKIVO Backup & Replication v7.2 (więcej: https://makeittogether.pl/nowa-wersja-nakivo-backup-replication-v7-2-juz-dostepna/), a już można zapisać się do programu beta testów nowej wersji, która wprowadza jeszcze więcej funkcji do oprogramowania.

Co nowego w wersji v7.3? Zmiany w deduplikacji. Nowa wersja NAKIVO Backup & Replication wprowadza wsparcie dla deduplikacji przy wykorzystaniu m.in. takich rozwiązań jak EMC Data Domain, HP StoreOnce, NEC Hydrastor, Quantum DXi oraz innych, które mogą być wskazane jako lokalizacja docelowa dla kopii zapasowych – a wszystko to bez spadku wydajności procesu tworzenia backupów.

Dodatkowo w becie  mamy możliwość wyboru specjalnego trybu repozytorium, który cechuje specyficzna architektura, stworzona tak, by współpraca NAKIVO Backup & Replication z urządzeniami do deduplikacji stała na jak najwyższym poziomie i zapewniała wysoką wydajność backupu.

Możliwa jest rejestracja w programie beta testów, wystarczy wypełnić odpowiedni formularz na stronie producenta: https://www.nakivo.com/resources/releases/v7.3/