Przekształcenie rozwiązania w zakresie tworzenia kopii zapasowych od wewnątrz Głos zabiera główny architekt Oracle w firmie EMC (Chief Oracle Architect) Na czym polega przekształcenie rozwiązania w zakresie tworzenia kopii zapasowych i dlaczego ma ono takie kluczowe znaczenie dla kondycji firmy i jej powodzenia? W tej sesji Pytań i odpowiedzi (Q&A), Darryl Smith, główny architekt Oracle EMC (Chief Oracle Architect) i weteran wojen backupowych, przedstawia punkt widzenia człowieka z wewnątrz na temat potrzeby przekształceń rozwiązania w zakresie tworzenia kopii zapasowych oraz wpływu, jakie ono wywiera na dział IT firmy EMC i na nasze firmy. Jeśli Twoja infrastruktura do tworzenia kopii zapasowych nie może sobie poradzić z eksplozją danych lub sprostać mobilności przetwarzania w chmurze, ucierpi na tym Twoja baza danych... Dlatego też niesamowicie ważne jest to, by infrastruktura lepiej adaptowała się do zmian technologicznych i była o wiele dynamiczniej skalowalna niż w chwili obecnej. Darryl Smith Smith, który odpowiada za wszystkie bazy danych EMC, przede wszystkim za bazę Oracle, ale też SQL Server, MySQL, Postgres oraz Greenplum, opisuje zmiany w zakresie zatrudnienia i procesów, jakie przeprowadził dział IT firmy EMC i szalenie istotne skutki, jakie zmiany te przyniosły. Spogląda on również w przyszłość i nakreśla swoją wizję idealnego rozwiązania backupowego. Więcej informacji i źródeł znajduje się na stronie: http://poland.emc.com/backupleader DLACZEGO TWORZENIE KOPII ZAPASOWYCH JEST DLA PANA, JAKO DLA ARCHITEKTA BAZY ORACLE TAKIE, WAŻNE? Jestem odpowiedzialny za to, by bazy danych EMC były w dobrej kondycji, sprawnie działały i były w stanie obsługiwać naszych użytkowników biznesowych, dostarczając im informacji, jakich potrzebują. Jeśli ja albo mój zespół nie pojawimy się w pracy, wszystko stanie. Jeśli baza danych obsługująca Waszą aplikację CRM lub aplikację do obsługi klienta, albo też jakąkolwiek inną, nie funkcjonuje, nie działa też Wasza aplikacja. A żebym ja mógł wykonywać swoją pracę, niesamowicie potrzebny jest backup. Jednym z głównych wyzwań, gdy rozpoczęliśmy podróż na chmurę, było to, że nasza infrastruktura do tworzenia kopii zapasowych nie nadążała za zmianami. Polegaliśmy na infrastrukturach historycznych i rozwiązaniach backupowych typu point-to-point. To nie dawało mi spokoju i nie daje wielu firmom w chwili obecnej. ULOTKA WIĘC PRZEKSZTAŁCENIE ROZWIĄZANIA W ZAKRESIE TWORZENIA KOPII ZAPASOWYCH JEST SPRAWĄ WIELKIEJ WAGI? Tak. Jest to naprawdę coś, co musimy zrobić. Nie można tworzyć dalej kopii zapasowych w taki sposób, jak zawsze, ponieważ stary sposób nie jest skalowalny i nie sprawdza się w zwirtualizowanych infrastrukturach chmurowych. Powodem jest to, że wszystkie aplikacje, od małych systemów rezerwacji pokoi konferencyjnych
do najważniejszych dla działań firmy aplikacji ERP do zarządzania, czy też aplikacje do i klienta tak naprawdę kręcą się wokół danych. Dlatego właśnie tak ważna jest ochrona danych, a bez przekształceń rozwiązania w zakresie tworzenia kopii zapasowych nie jest ona możliwa. I MOŻE TO MIEĆ WPŁYW NA WYSIŁKI W KIERUNKU PRZENOSZENIA DO CHMURY I WIRTUALIZACJĘ? Dokładnie. Jeśli Twoja infrastruktura do tworzenia kopii zapasowych nie może sobie poradzić z eksplozją danych lub sprostać mobilności przetwarzania w chmurze, ucierpi na tym Twoja baza danych. A to może nieść za sobą przeróżne skutki, od zmniejszenia wydajności aplikacji do utraty danych lub nawet całkowitej niewydolności aplikacji, co oczywiście stawia firmę w sytuacji krytycznej. Dlatego też niesamowicie ważne jest to, by infrastruktura lepiej adaptowała się do zmian technologicznych i była o wiele dynamiczniej skalowalna niż w chwili obecnej. CO ZROBILIŚCIE W CIĄGU OSTATNICH KILKU LAT W CELU PRZEKSZTAŁCENIA ROZWIĄZANIA W ZAKRESIE TWORZENIA KOPII ZAPASOWYCH? W dniu dzisiejszym, jeśli chodzi o serwery, jesteśmy zwirtualizowani w 94%. Jeśli chodzi o bazę danych, jesteśmy zwirtualizowani w około 84% i kontynuujemy proces tak szybko jak to jest możliwe. A to ma ogromny wpływ na sposób tworzenia kopii zapasowych. Kiedy zaczynaliśmy, stosowaliśmy tradycyjne metodologie backupowe. Tworzyliśmy kopie zapasowe przy użyciu tradycyjnego narzędzia RMAN według naszego programu do planowania backupu, EMC NetWorker i kopiowaliśmy na urządzenia taśmowe albo urządzenia dysk- taśma wirtualna, zabezpieczane przez dysk. Taśmy, rzecz jasna, są bardzo starą technologią, więc zastąpiliśmy je wirtualnymi bibliotekami taśmowymi. Jednak nawet te nie były skalowalne i stale mierzyliśmy, obliczaliśmy i ograniczaliśmy korzystanie z tych zasobów. To było sedno naszego problemu: Mieliśmy ograniczona ilość zasobów, rosnącą liczbę baz danych oraz zwiększającą się ilość danych, które musiały być zabezpieczane kopiami zapasowymi. Aby dotrzymywać kroku procesowi wirtualizacji, w zasadzie pozbyliśmy się wszystkich naszych platform historycznych. Nawet nasze węzły składowania systemu NetWorker zostały zwirtualizowane. NA JAKIM ETAPIE ZNAJDUJE SIĘ OBECNIE PRZEKSZTAŁCANIE ROZWIĄZANIA W ZAKRESIE TWORZENIA KOPII ZAPASOWYCH? Teraz, po 24 miesiącach, przechodzimy do skalowania naszej infrastruktury. Pozbyliśmy się już urządzeń taśmowych i zastępujemy urządzenia do taśm wirtualnych sprzętem Data Domain, który ma o wiele większą pojemność i moce przerobowe, a dzięki funkcji deduplikacji ma też możliwość przechowywania danych przez o wiele dłuższy czas. Ten pierwszy krok naprawdę pomógł nam zmniejszyć ograniczenia pojemności. Teraz wiemy, że gdybyśmy potrzebowali odzyskać dane z kopii zapasowych, możemy to zrobić całkiem szybko i nie musimy polegać na taśmach i przechowywaniu danych poza firmą. Nadal jednak zarządzamy backupami tak, jakby obowiązywały nas te stare ograniczenia i to właśnie na usprawnieniu tej części musimy się teraz skupić.
Wykonaliśmy też nieco pracy database-as-a-service, gdzie mogliśmy w pełni zautomatyzować tworzenie kopii zapasowych i odzyskiwanie danych, tak że teraz w zasadzie wszystko działa bez zarzutu. Gdy jeszcze nie mieliśmy takiego nawału danych i informatyki mobilnej, byliśmy w stanie konfigurować nasze backupy i w pewnym sensie o nich zapominać, co było całkiem fajne. Teraz życie jest o wiele bardziej skomplikowane, ale dzięki temu, że możemy zautomatyzować nasze backupy i w pełni je zaprogramować, nie musimy się już dłużej martwić o to, czy się odbędą, ponieważ usunęliśmy zmienne. Postępujemy tak samo z niektórymi z naszych bardzo dużych baz danych. Pracowaliśmy z zespołami ds. tworzenia kopii zapasowych i wypracowaliśmy rozwiązanie backupu odciążonego (offloaded backup). Co mam na myśli: bierzemy klon pamięci masowej, instalujemy na serwerze proxy lub na węźle składowania systemu NetWorker i tworzymy kopie zapasowe bazy danych stamtąd. W tym przypadku kopia zapasowa bazy danych lub serwer proxy są podłączone bezpośrednio do systemu Data Domain, więc nie mamy ograniczeń co do zasobów. Obecnie te backupy działają bez zarzutu i są bardzo szybkie. Tak więc są to dwa przykłady, nad czym pracowaliśmy z zespołem ds. tworzenia kopii zapasowych w celu zapewnienia backupu, który jest niezawodny i skalowalny, który można w zasadzie skonfigurować i o nim zapomnieć. WYGLĄDA NA TO, ŻE WSPÓŁPRACUJE PAN TERAZ INACZEJ Z ZESPOŁEM DS. TWORZENIA KOPII ZAPASOWYCH. JAK ZMIENIŁY SIĘ PROCESY? Wymiana naszej infrastruktury jest jedynie początkiem przekształceń sposobu, w jaki działa nasza infrastruktura do tworzenia kopii zapasowych. Naprawdę musimy skupić się bardziej na procesach i procedurach. Dobrze jest mieć, przykładowo, program do planowania obejmujący całą firmę. Jednak próby zarządzania w sposób manualny indywidualnymi komponentami i zasobami kłócą się ze zdolnością do dynamicznej skalowalności i nie dają możliwości szybkiej adaptacji do zmian, jakiej przetwarzanie w chmurze naprawdę wymaga. Tak naprawdę kluczem do całej tej transformacji jest połączenie wszystkich tych indywidualnych grup i członków oraz umiejętności w jeden większy zestaw umiejętności. Ciągle o tym mówimy, omawiając kwestie transformacji IT - wszystkie umiejętności powinny iść w parze. To nie musi oznaczać, że jedna osoba ma znać się na wszystkim, ale ludzie posiadający różne zestawy umiejętności muszą ze sobą ściśle współpracować, by naprawdę stać się częściami zespołu tej bazowej architektury, i aby dzielić się wiedzą. JAK ZMIENIŁY SIĘ RELACJE Z ZESPOŁEM DS. TWORZENIA KOPII ZAPASOWYCH? No cóż, nasze relacje stawały się napięte. Mieliśmy liczne problemy z tworzeniem kopii zapasowych, a zespoły ds. tworzenia kopii zapasowych ciągle musiały rozwiązywać problemy. Stres dotykał obu stron, zarówno zespół ds. tworzenia kopii zapasowych, jak i administratorów baz danych. To niosło za sobą liczne frustracje. Wykonywali swoje codzienne obowiązki i stale rozwiązywali problemy. To był wieczny problem i nie tylko stanowił obciążenie dla wzajemnych relacji, ale też wpływał na naszą zdolność do świadczenia usług użytkownikom biznesowym. zespół ds. tworzenia kopii zapasowych działa raczej na zapleczu. Nie słyszy się o nich, nie uważa za część działu IT jako takiego, nie biorą udziału w procesie decyzyjnym. Po prostu robią kopie zapasowe. Jednak taki sposób myślenia lub kultura myślenia już nie działa. Zespół ds. tworzenia kopii zapasowych naprawdę musiał stać się w większym stopniu częścią szeroko pojętego zespołu IT i wspomóc
całościowe przekształcenia w tym dziale. Jeśli tak się nie stanie, pojawią się problemy. Bazy danych nie będą działały tak, jak powinny; będą spowalniać, próbując tworzyć kopie zapasowe. W przypadku awarii, nie będzie się w stanie odzyskać systemów ani danych. Backup naprawdę musi zostać bardziej zintegrowany z głównym nurtem, teraz bardziej niż kiedykolwiek wcześniej. DOKĄD ZMIERZACIE? JAKA JEST IDEALNA SYTUACJA W ZAKRESIE TWORZENIA KOPII ZAPASOWYCH? No cóż, dziś jeszcze nie jesteśmy w stanie w 100% oferować tworzenia kopii zapasowych jako usługi ( backup-as-a-service ), ale robimy to w ograniczonej formie. Na przykład, inne nasze oferty usług typu IT-as-a-service, infrastructure-as-a-service oraz database-as-a-service wykorzystują backupy, a backupy te są w pełni zautomatyzowane i dostarczane jako usługa. Tak więc celem przekształcania naszej infrastruktury do tworzenia kopii zapasowych jest to, by administratorzy ds. tworzenia kopii zapasowych byli odpowiedzialni za tę infrastrukturę, planowanie pojemności, aby zapewnić nam wystarczającą pojemność. Dla mnie, jako dla konsumenta i administratora baz danych, który jest odbiorcą tych usług tworzenia kopii zapasowych, istotna jest możliwość konfigurowania swoich własnych backupów i wykonywania ich w dowolnych ilościach oraz możliwość odzyskiwania danych wedle potrzeby bez konieczności polegania na innej grupie, jeśli chcę, by wszystko szło sprawnie. Tak więc dla mnie idealna sytuacja to taka, gdzie obsługuję konsolę, na której mogę zaplanować tworzenie wszystkich kopii zapasowych baz danych i nie musze martwić się o to, czy wystarczy mi pojemności, czy nie. To trochę tak jak z zasilaniem. Kiedy włączam światła, oczekuję, że światła się zaświecą, bo będę miał wystarczające zasilanie, by tak się stało. Chciałbym, żeby wykonywanie kopii zapasowych było równie proste. JAKIE TECHNOLOGIE EMC STOSUJECIE? JAK ZMIENIŁY ONE REGUŁY GRY? Jednym z pierwszych kroków, jakie podjęliśmy był zakup systemów EMC Data Domain, jeszcze zanim EMC kupiło tę firmę. Wybraliśmy ich ze względu na deduplikację. Oczywiście mieliśmy już Avamar, a ten wykonuje całkiem niezłą deduplikację. Świetnie się nadaje do tworzenia kopii zapasowych systemów operacyjnych i pulpitów, a my w tym celu wiele zainwestowaliśmy w Avamar. Jeśli chodzi o bazy danych, potrzebowaliśmy czegoś z dużo większą pojemnością i dlatego właśnie zdecydowaliśmy się na Data Domain. Zawsze mieliśmy też system NetWorker, co bardzo upraszcza tworzenie kopii zapasowych. Administratorzy baz danych przyzwyczajeni są do używania aplikacji RMAN tworzenia kopii zapasowych, ale RMAN musi zapisywać na urządzenia taśmowe. Systemy operacyjne zwykle nie mają wbudowanych urządzeń taśmowych. Tak więc NetWorker działa jako urządzenie do wirtualnej taśmy dla backupów RMANa, co dla nas jest pełną integracją, a administrator baz danych może rozpocząć tworzenie kopii zapasowych, a NetWorker, poprzez węzły składowania, zabezpieczy je, w naszym przypadku, na urządzeniu Data Domain. Taka integracja jest bardzo istotna. Jedną z nowszych technologii, jakim się przyglądamy, jest DD Boost od Data Domain. Również integruje się z narzędziem RMAN. Administrator baz danych może tworzyć tradycyjne kopie zapasowe za pomocą narzędzia RMAN, korzystać z zalet produktu takiego jak DD Boost, bez specjalnej konieczności dokładnego zaznajomienia się z tym produktem. Jednak pełna kontrola jest wtedy w rękach administratora baz danych.
Innym powodem, dla którego koniecznie chcemy wprowadzić DD Boost jest to, że redukuje on liczbę zasobów wymaganych do wykonania kopii zapasowych, ponieważ duża część danych z deduplikacji stosowanej przy wykonywaniu backupu odciążana zostaje na serwer bazy danych, więc o wiele mniej danych przesyłanych zostaje przez sieć. To z kolei pozwala mi zabezpieczać kopiami zapasowymi o wiele więcej elementów jednocześnie, czy będą to bazy danych czy systemy operacyjne. Co więcej, oznacza to, że moje kopie zapasowe będą mogły być przesyłane o wiele dalej. A zatem teraz mogę mieć infrastrukturę, która będzie szła ręka w rękę z mobilnością przetwarzania w chmurze. Kolejną rzeczą, jaką robimy to tworzymy kopie zapasowe bezpośrednio na Data Domain. Możemy więc używać produktów takich jak VMware Data Director, konfigurować niektóre nasze pamięci masowe jako Data Domain NFS mount, i zapisywać klony pamięci masowej prosto do urządzenia Data Domain. Możemy robić to samo z takimi narzędziami, jak Export lub Data Pump od Oracle lub z backupami ręcznymi. W SQL Server czasem po prostu wykonujemy kopie zapasowe systemu plików ręcznie i przesyłamy prosto do Data Domain. EMC 2, EMC i logo firmy są zarejestrowanymi znakami towarowymi lub znakami towarowymi firmy EMC Corporation w Stanach Zjednoczonych i innych krajach.vmware jest zarejestrowanym znakiem towarowym lub znakiem towarowym firmy VMware Inc. w Stanach Zjednoczonych i innych krajach. Copyright 2012 EMC Corporation. Wszelkie prawa zastrzeżone. Opublikowano w Polsce. 11/12 Ulotka H11297. http://poland.emc.com/ EMC uznaje informacje zawarte w niniejszym dokumencie za rzetelne w dniu publikacji. Informacje mogą ulec zmianie bez uprzedniego powiadomienia.