ナヌザヌデヌタのバックアップ

少し前、EMC補品ラむンテストの䞀環ずしお、EMC Avamar Virtual Edition゜リュヌションを䜿甚する機䌚がありたした。 この出版物でこの経隓を皆さんず共有したいず思いたす。







問題履歎



さたざたな䌁業の同僚ず話をした埌、私は倚くの人が䌚瀟の埓業員のワヌクステヌションをバックアップするこずを怠り、本番アプリケヌションのコピヌのみに限定しおいるず結論付けたした。



䞀方では、これは理解できる-「戊闘」サヌビスであっおも、「倧衆に行った」確立された慣行はただ倚くない。 したがっお、重芁なサヌビスに察しお優れたRTOおよびRPOパフォヌマンスを確保するこずは、倧䌁業および䞭芏暡䌁業のIT郚門の䞻な頭痛の皮の1぀です。 カスタムマシンのバックアップなど、些现なこずに時間を費やすこずは蚱されない莅沢です。



ただし、実際には、ワヌクステヌションの障害により、叀いデバむスから新しいデバむスぞのハヌドドラむブの転送その埌のむンベントリおよびアカりンティングの困難性、たたはナヌザヌデヌタの完党な損倱が発生するこずを意味したす。



もちろん、重芁なデヌタをNASサヌバヌや䌁業のファむルホスティングサヌビスに保存するこずは、長い間良い圢ず考えられおきたした。 この堎合、すべおの重芁な情報は保存されたすが、䞀時的/重芁ではないデヌタは倱われたす。 さらに、アむロンを亀換した埌、ナヌザヌは自分の職堎をパヌ゜ナラむズし盎す必芁がありたすが、それは圌の気分を高めたせん。



おそらく、これはビゞネススケヌルでは重芁ではありたせんが、実際には運甚䞊の遅延に぀ながり、故障が発生した堎合のダりンタむムを増加させ、IT郚門ず内郚顧客の間の緊匵をわずかに増加させたす。 そしお埌者は、倚くのITマネヌゞャヌが䞍圓に無芖する重芁な芁玠です。



解決策


この問題は、いく぀かの方法で解決できたす。

1.すべおをそのたたにしたす。

2.埓業員の職堎を仮想化したす。

3.ゞョブのバックアップサヌビスを実装したす。



もちろん、2番目のシナリオは、さたざたな゜ヌスで繰り返し説明され、実蚌されおいる最倧の利点を提䟛したす。 ただし、これは実装するのにかなり高䟡な゜リュヌションです。 そしお、職堎を組織化する「叀兞的な」スキヌムから仮想化されたものぞの移行は、技術的および運甚䞊の倚くの困難に関連しおいたす。



䞀方、䞀元化されたバックアップツヌルは実装が簡単で、むンフラストラクチャの倧芏暡な再構築を必芁ずせず、倚くの堎合より予算がかかりたす。



EMCは䜕を提䟛できたすか



最近、EMCは、新しいDPAD、デヌタ保護および可甚性郚門の䜜成「合䜵」を参照を含む重芁な構造䞊の倉曎を受けたした。 名前が瀺すように、この郚門には、デヌタ保護ずアクセシビリティを敎理するための゜リュヌションが含たれおいたす。 これたでのずころ、保護゜リュヌションにのみ関心がありたす。

そのため、珟時点では、EMC DPADはData Domain、NetWorker、Avamarの3぀のデヌタバックアップ゜リュヌションを提䟛できたす。 この蚘事では、EMC Avamar゜リュヌションの説明に集䞭したす。 ただし、各補品のいく぀かの蚀葉はただ蚀わなければなりたせん。



Networker


䞀元化されたデヌタのバックアップずリカバリのための゜フトりェア。 自動化、集䞭管理、監芖のための幅広い機胜を備えおいたす。 そしお䞀般的に、倧芏暡で耇雑なむンフラストラクチャでの䜜業に最適化されおいたす。



デヌタドメむン


バックアップを保存するためのハヌドりェア゜リュヌションは、CIFS、NFS、Boost、VTL仮想テヌプラむブラリで動䜜したす。 独自のバックアップツヌルがない堎合、Data DomainにはNetWorkerなどの個別のバックアップ゜フトりェアが必芁です。 Boostテクノロゞヌの人気が高たっおいたす。これは、重耇排陀されたデヌタを転送し、Data Domainシステムを管理するための高床なむンタヌフェヌスです。



アバマヌル


ワヌクステヌションおよび䞭/䜎負荷のサヌビスおよびアプリケヌションのバックアップコピヌを䜜成および保存するように蚭蚈されたハヌドりェアおよび゜フトりェア゜リュヌション。



どのように機胜したすか



Avamarは、埓来のサヌバヌ/クラむアントスキヌムに埓っお動䜜したす。 クラむアントアプリケヌションは、保護されたマシンにむンストヌルされ、デヌタを収集、重耇排陀重耇デヌタを陀く、および送信したす。

したがっお、コピヌは垞に増分です-぀たり 最初に、システムはデヌタの完党なコピヌを䜜成し、次にブロックのみを倉曎したす。 これにより、チャネルの負荷ずストレヌゞ容量のコストを倧幅に削枛できたす。 増分バックアップず混同しないように、Avamarは合成完党バックアップを保持しおいたす。



そしお、Avamarの仕事の重芁な原則は、たさに重耇排陀アルゎリズムです。

䞀蚀で蚀えば、このテクノロゞヌは、特定のコンピュヌタヌからだけでなく、バ​​ックアップがすでに䜜成されおいるすべおの゜ヌスからの䞍芁なデヌタ転送を排陀したす。



以䞋は、Avamarで䜿甚される重耇排陀アルゎリズムのもう少し詳现な説明です。
Avamarでは、デヌタの「゜ヌス」で、いわばクラむアントで重耇排陀が行われたす。

たずえば、誰もバックアップしたこずがないたったく新しいファむルをバックアップするタスクを分析しおみたしょう。

1バックアップのタスクが来たした。

2クラむアントAvamar'aは、プロセスavtar.exeを開始したす。これは、重耇排陀のさらなるプロセスに関䞎しおおり、最初にすべおの凊理がファむルレベルで行われたす。

3SHA-1アルゎリズムを䜿甚しお、ファむルメタデヌタの160ビットハッシュ倀が蚈算されたす。

4Avtarは、「ファむルハッシュ」のデヌタベヌス-F_cache.datで受信したハッシュを探したす。 クラむアントのC\ Program Files \ avs \ varなどにあり、バックアップ䞭にF_cache.datはRAMに完党にアンロヌドされたす。

5ファむルが新しいため、そのハッシュはクラむアントのF_cache.datで怜出されず、同じF_cache.datのAvamarのサヌバヌ偎で怜玢が実行されたすが、すべおの以前のバックアップからハッシュデヌタベヌスが既に収集されおいたす。ワヌクステヌション;

6しかし、ハッシュ倀はありたせん。 その埌、avtarプロセスはブロックレベルに移行し、すでにデヌタブロックのバックアップに぀いお説明しおいたす。

7デヌタは、1 Bから64 KB、平均25 KBのさたざたな長さのセグメントに分割されたす。

8その埌、セグメントは30〜50圧瞮されたすが、セグメントが25を超えお圧瞮されない堎合、圧瞮せずにさらに凊理が行われたす。

9160ビットのハッシュは、圧瞮/非圧瞮セグメントごずに蚈算されたす。

10ハッシュは、8,000〜30,000ハッシュの耇合に結合されたす。

11次に、ハッシュ合成のハッシュが蚈算されたす。

12耇合材料のハッシュハッシュは再び耇合材料に結合されたす。

13そしお倧きなルヌトハッシュが蚈算されたす-これは耇合ハッシュの耇合ハッシュのハッシュです

14Avtarは、すでに「ブロックハッシュ」のデヌタベヌスP_cache.datで受信したルヌトハッシュ倀を探したす。

15クラむアントでルヌトハッシュが芋぀からない堎合、怜玢はAvamarのサヌバヌ偎で行われたす。

16Avamarサヌバヌでルヌトハッシュが芋぀からない堎合、怜玢はハッシュコンポゞットのハッシュによっお既に実行されおおり、たずクラむアントで、次にサヌバヌで実行されたす。

17少なくずも䜕らかのハッシュが芋぀かるたで続きたす。

18すべおの䞀意のデヌタブロックが芋぀かり、そのハッシュがどこにも蚘録されおいない堎合にのみ、ワヌクステヌションからavamarサヌバヌぞのデヌタ転送が開始されたす。

19avamarのサヌバヌでは、保存されたばかりの「デヌタブロック-ハッシュ」の束が䞀意のむンデックスの䞋に蚘録されたす。

20バックアップマップが䜜成されたす-これらはファむルおよびブロックぞのリンクです。

21そしお、これらはすべおPostgreSQLデヌタベヌスで行われたす。

22バックアップタスクの番号が蚘録され、それに応じお、どのクラむアントからバックアップが䜜成されたか、バックアップを保存する時間、むンデックスツリヌ、バックアップカヌドなどが決定されたす。 など



このようなアルゎリズムには、コむンの2぀の偎面がありたす。



1.これにより、デヌタ䌝送チャネルの幅を倧幅に節玄でき、リモヌトサむト䟋ブランチネットワヌクのワヌクステヌションの゜ヌスからでもバックアップできたす。

2.ただし、゜ヌスでの重耇排陀には、プロセッサパフォヌマンスずRAM容量の玄5〜10が必芁です。 サヌバヌにずっおは、これは非垞に重芁な数字になりたすが、ワヌクステヌションにずっおは目に芋えたせん。



EMC Data Domainず統合する堎合、サヌバヌはロヌカルストレヌゞにメタデヌタのみを保存し、デヌタ自䜓は重耇排陀埌にすでに圧瞮され、Data Domainに配眮されたす。 このようなスキヌムは、DDで䜿甚されるブヌストテクノロゞヌで機胜したす。



回埩手順は次のずおりです。

䞀般的に、OSずAvamarクラむアントがむンストヌルされた新しい/固定デバむスが必芁です。 Windowsデバむスは䟋倖です。ブヌタブルパヌティションを備えたファむルシステムをバックアップに含めるこずができたす。これにより、ベアメタルナヌティリティを䜿甚しおバックアップをベアメタルに展開できたす。



建築



Avamarは゜フトりェア補品ずハヌドりェア補品の組み合わせであるため、各゜リュヌションは異なるノヌドのセット-ノヌドから構成されたす。 ノヌドは、Avamarがデプロむされたホスト制埡ノヌドたたはディスクストレヌゞ100以䞊のノヌドです。

Avamarグリッドがあり、単䞀ノヌド構成この堎合は1぀のストレヌゞノヌドずRAIN独立ノヌドの冗長アレむのような構成の䞡方で発生したす



ノヌドのタむプに関する詳现


  • ナヌティリティノヌド-必芁なすべおのサヌビスを管理したす
  • ストレヌゞノヌド-デヌタを保存したす。M600、M1200、M2400の3぀のタむプがあり、パフォヌマンスず容量が異なりたす
  • スペアノヌド-ノヌドに障害が発生した堎合のバックアップノヌド。手動でアクティブ化され、運甚されたす
  • NDMPノヌド-NDMPを䜿甚したAvamarのノヌド
  • メディアアクセスノヌド-テヌプデバむスを接続するためのノヌド






さらに、EMCは顧客に仮想実行モデルであるAVEAvamar Virtual Editionを提䟛しおいたす。 これを行うには、Avamarサヌバヌを備えた仮想マシンが展開されるハむパヌバむザヌが必芁です。 バックアップクラスタデヌタストアたたは倖郚ストレヌゞシステムがバックアップストレヌゞの堎所ずしお䜿甚されたす。



Virtual Avamarにはいく぀かのバヌゞョンがありたす-0.5TB。 1TB; 2TB; 4TBの䜿甚可胜なボリュヌム。 これは、䌚瀟が取埗したラむセンスによっお管理されたす。



さらに、EMCは、掚奚ハむパヌバむザヌずしおのVMwareず掚奚ストレヌゞずしおのEMC Data DomainずのAVEの䟿利な統合を保蚌したす。



私は偶然、Avamar GridずAvamar Virtual Editionの䞡方で動䜜したした。



EMCにはAvamar Virtual Editionの詊甚版があるため、むンストヌル方法を玹介したす。



Avamar仮想アプラむアンスのむンストヌルプロセス



Avamar仮想アプラむアンスのむンストヌルプロセス
VMwareクラスタヌが高くなっおいるため、むンストヌルは非垞に簡単です。

1.パヌトナヌリ゜ヌスEMC .ovfからダりンロヌドした仮想マシンのむメヌゞず.vmdkディスクをむンストヌルパッケヌゞず共に展開したす。

2. AVEのバヌゞョンに応じお、必芁な数の仮想ディスクを䜜成し、AVEでVMに接続したす。 私たちの堎合、これらは3぀の250 GBディスクです。

3. VMを展開しお起動するず、必芁なすべおのリポゞトリが内郚にある、裞のSUSE Linux Enterpriseが取埗されたす。 接続は仮想コン゜ヌルvSphereを介しお実行され、管理はコン゜ヌルを介しお実行されたす。 スクリプト/usr/local/avamar/bin/ave-part.plを䜿甚しお、AvamarをむンストヌルするOS を準備したす。

4.ネットワヌクむンタヌフェむスを蚭定したす。 これを行う最も簡単な方法はdpnnetutilナヌティリティを䜿甚するこずです。これはすでに仮想マシンの䞀郚ですが、 YaST2を䜿甚するこずもできたす。 ネットワヌクむンタヌフェむスの構成が完了したら、VMを再起動する必芁がありたす。

5. ./usr/local/avamar/src/avinstaller-bootstrap-version.sles11_64.x86_64.runコマンドでAVEむンストヌルりィザヌドを展開したす。 その埌、起動したす。 むンストヌルりィザヌドには、 Avamar_Server_IP 8543 / avi / avigui.htmlずいう䟿利なWebベヌスのむンタヌフェむスがありたす。







Avamarのむンストヌルおよび構成プロセスには時間がかかり、ナヌザヌの参加が必芁になりたす。







8. Webむンタヌフェヌスでむンストヌルが完了したら、コン゜ヌルで最終スクリプトを実行したす

./usr/local/avamar/bin/ave-post.sh



9.サヌバヌのむンストヌルの最埌に、管理コン゜ヌルをダりンロヌドしおむンストヌルする必芁がありたす。 これを行うには、ブラりザヌでサヌバヌのブラりザヌIPアドレスステップ4で蚭定したものを開くだけです。 Webむンタヌフェヌスを䜿甚しお、さたざたなオペレヌティングシステム甚のクラむアントず、Windows甚のベアメタルナヌティリティをダりンロヌドできたす。 たた、Avamarでできるこずすべおに必芁なすべおのドキュメントがありたす。









運営管理


運営管理
これは、むンストヌルされおいるAvamarの管理者コン゜ヌルのようです。







クラむアントを远加する


管理者には、クラむアントをアクティブ化远加するためのいく぀かのシナリオが提䟛されたす。 いずれの堎合も、保護されたマシンにクラむアントを最初にむンストヌルする必芁がありたす。



これに続いお、次のシナリオが可胜です。

1.ナヌザヌは、クラむアントを介しお、アクティベヌションのリク゚ストを送信できたす。







2.管理者はクラむアントを「ピヌス単䜍で」アクティブ化し、IPアドレスを瀺すこずでアクティブ化するコマンドを送信できたす。

3.管理者は、IPアドレスのプヌルを指定するこずにより、クラむアントプヌルをアクティブ化できたす。



最初のシナリオでは、クラむアントは自動的にルヌトドメむンに远加され、デフォルトのポリシヌがそれに適甚されたす。 2番目ず3番目のシナリオでは、管理者は远加されたクラむアントのドメむンずポリシヌを事前定矩できたす。



ドメむン


集䞭管理の抂念には、階局的な「ドメむン」が含たれたすWindows ADず混同しないでください。 実際には、クラむアント、コピヌポリシヌ、ナヌザヌ、および委任された暩限のリストを含む、ツリヌのようなフォルダヌ構造にすぎたせん。



したがっお、コピヌポリシヌを䜿甚しお、保護されたデバむスをさたざたなグルヌプに結合し、さたざたなナヌザヌのアクセスをそれらに制限できたす。



政治家
コピヌポリシヌは、すべおのバックアッププロパティを定矩したす。



スケゞュヌル






メンテナンス時間






メンテナンスりィンドりには、チェックポむントの䜜成、チェックポむントのチェック、ガベヌゞコレクションが含たれたす。

チェックポむントに぀いお少し-これはサヌバヌ自䜓のバックアップです。 将来これらのチェックポむントでホスト\仮想マシンがクラッシュした堎合、デヌタ、保存されたクラむアント、ナヌザヌ、ドメむン、およびポリシヌを倱うこずなく、管理サヌバヌを埩元できたす。



オブゞェクトをコピヌする






保持期間のコピヌ






い぀でも䜓系的なバックアップをスケゞュヌルしたり、ストレヌゞを遞択したりできたす。 ほずんどのオペレヌティングシステムがサポヌトされおおり、コピヌする特定のディレクトリを遞択できたす。 これにより、必芁なデヌタのみを保護し、䞍芁なコピヌを保存するコストを削枛できたす。



さらに、ポリシヌを䜜成するずきに、コピヌの有効期限を指定できたす。 この期間が過ぎるず、コピヌは「期限切れ」ず芋なされ、リポゞトリから削陀されたす。



䟋
ルヌトドメむンにアクセスできるルヌトナヌザヌがいたす。 すべおの顧客に。

次に、すべおのナヌザヌを郚門営業、マヌケティング、倉庫、物流などに分割したす。

各ドメむン郚門に察しお、コピヌポリシヌを管理するナヌザヌを割り圓おるこずができたす。 たた、すべおの郚門のコピヌを個人的に管理できたす。

同時に、ナヌザヌにはさたざたなアクセスレベルがありたす。ステヌタスの衚瀺、コピヌのみ、回埩のみ、フルアクセスです。 ぀たり 郚門長は蚈画倖のバックアップを開始する暩利があり、残りの埓業員は既存のコピヌからのみ埩元する暩利がありたす。



バックアッププロセスを管理するには、バックアップ管理者が管理コン゜ヌルをむンストヌルする必芁がありたす。

ナヌザヌは、自分のデヌタのみを衚瀺および埩元できたす。

これを行うには、デバむスにむンストヌルされおいるクラむアントから開くこずができるWebむンタヌフェむスを䜿甚したす。



VMwareずの統合


Avamarでは、VMware vSphere ESXiハむパヌバむザヌで実行されおいる仮想マシンをコピヌできたす。 このため、各VMにクラむアントをむンストヌルする必芁はありたせん。 ハむパヌバむザヌ党䜓のクラむアントずしお機胜するクラスタヌに仮想マシンを展開するだけで十分です。 これはAvamarプロキシず呌ばれ、バックアップにはVADPデヌタ保護甚のvStorage APIテクノロゞヌを䜿甚したす。 AvamarをESXiず統合するには、vCenterが必芁です。

むンストヌルプロセス
Avamarプロキシ配垃はWebむンタヌフェヌスからアクセスでき、.ovaファむルです。

.ovaをデプロむしおシステムをロヌドするず、仮想マシンのネットワヌクむンタヌフェむスを構成するためのスクリプトがすぐに開始されたす

次に、AvamarサヌバヌのあるVMの/usr/local/avamar/var/mc/server_data/prefs/mcserver.xmlファむルで、次の行にTRUEを曞き蟌みたす。entry key = "allow_duplicate_client_names" value = "true"



VMware仮想マシンのみをコピヌする堎合は、VDP-A補品-vSphere Data Protection Advancedを賌入できたす。 この補品もVADPテクノロゞヌに基づいおいたす。 本質的に、VDP-AはAvamar Virtual Editionであり、VMwareの䞋で「剥ぎ取られ」、基盀ずなっおいたす。 仮想マシンず䞀郚のMicrosoftアプリケヌションをバックアップする機胜のみを保持しおいるため、EMC AVEよりも安䟡です。



Data Domain 160の䟋を䜿甚したData Domainずの統合


AvamarをDD、DDず統合する堎合、バックアップ自䜓の保存にのみ䜿甚され、すべおのメタデヌタずキャッシュはAvamarサヌバヌに残りたす。 デヌタはBoostプロトコルを䜿甚しお送信されたす。

統合
最初に、AvamarのナヌザヌをDDで䜜成する必芁がありたす。







次に、Avamar Administratorの[サヌバヌ]タブで[サヌバヌ管理]を遞択し、[アクション]> [デヌタドメむンシステムの远加]ボタンをクリックしたす。







提案されたすべおのフィヌルドに入力したす。サポヌトされおいるストリヌムの数を確認するには、[ ストリヌム情報を取埗 ]をクリックしたす。



同じりィンドりの[SNMP]タブに移動したす。 このプロトコルでは、AvamarサヌバヌはDDのステヌタスに関する情報を受信したす。







その結果、远加されたシステムが衚瀺されたす。







次に、DataSet蚭定の[DDにバックアップを保存する]チェックボックスをオンにするこずを忘れないでください。







芁玄する



EMC Avamarバックアップおよびリカバリ補品の䞻な利点は次のずおりです。



1.汎甚性-ほずんどの商甚オペレヌティングシステム、デヌタベヌス、サヌビスのサポヌト。

2.柔軟性-VMware vSphereの仮想バヌゞョンを含むさたざたな構成。

3.䜿いやすい-ナヌザヌフレンドリヌなクラむアントむンタヌフェむスずVMware vSphereずの統合。

4.収益性-クラむアントで重耇排陀を䜿甚するこずにより、デヌタチャネルの垯域幅芁件を明確に節玄できたす。



したがっお、50人以䞊のスタッフがいるので、デバむスを簡単にバックアップできたす。

ほずんどの堎合、仮想化むンフラストラクチャでは、Avamar VE仮想アプラむアンスずコピヌに十分なストレヌゞスペヌスで十分です。



これにより、資栌のある埓業員に技術的な問題や費甚をかけるこずなく、集䞭的な自動バックアップが可胜になりたす。



たた、倱われたナヌザヌデヌタを回埩する手順は、同じタむプのワヌクステヌションを亀換し、管理コン゜ヌルのいく぀かのボタンを抌すだけになりたす。



All Articles