人工知能
使用事例 1 ： Hadoop データのバックアップ
変更を提案
PDF
シナリオ（ Scenario ）
このシナリオでは、大規模なオンプレミスの Hadoop リポジトリがあり、ディザスタリカバリのためにバックアップを作成したいと考えています。しかし、お客様の現在のバックアップ解決策はコストが高く、 24 時間以上のバックアップウィンドウに悩まされています。
要件と課題
このユースケースの主な要件と課題は次のとおりです。
-
ソフトウェアの下位互換性：
-
提案する代替バックアップ解決策は、本番用 Hadoop クラスタで現在実行しているソフトウェアバージョンと互換性があることが必要です。
-
-
コミットされた SLA を満たすためには、代替の解決策で非常に低い RPO と RTO を達成することを推奨します。
-
ネットアップのバックアップ解決策で作成したバックアップは、データセンターのローカルに構築された Hadoop クラスタ、およびリモートサイトのディザスタリカバリロケーションで実行されている Hadoop クラスタで使用できます。
-
提案する解決策は対費用効果が高いものでなければなりません。
-
提案する解決策は、バックアップ処理中に実行中の本番環境の分析ジョブに与えるパフォーマンスへの影響を軽減する必要があります。
お客様の既存のバックアップソリューションx
次の図は、元の Hadoop ネイティブのバックアップ解決策を示しています。
本番環境のデータは、中間バックアップクラスタを通じてテープに保護されます。
-
hadoop distcp-update <hdfs1 ><hdfs2>` コマンドを実行することにより、 HDFS1 データが HDFS2 にコピーされます。
-
バックアップ・クラスタは NFS ゲートウェイとして機能し ' テープ・ライブラリを介して Linux'cp' コマンドを使用してデータを手動でテープにコピーします
元の Hadoop ネイティブバックアップ解決策には次のようなメリットがあります。
-
解決策は Hadoop ネイティブのコマンドをベースにしているため、新しい手順を習得する必要がなくなります。
-
解決策は、業界標準のアーキテクチャとハードウェアを活用しています。
元の Hadoop ネイティブバックアップ解決策には、次のような欠点があります。
-
バックアップ時間が長いと 24 時間を超えるため、本番環境のデータが脆弱になります。
-
バックアップ時間中にクラスタのパフォーマンスが大幅に低下します。
-
テープへのコピーは手動で行います。
-
バックアップ解決策は、必要なハードウェアと、手動プロセスに必要な人的時間の点でコストが高くなります。
バックアップソリューション
これらの課題と要件に基づいて、既存のバックアップシステムを検討し、 3 つのバックアップソリューションを提案しました。以降のサブセクションでは、解決策 A ～ 解決策 C というラベルの付いた 3 種類のバックアップソリューションについて説明します
解決策 A の略
解決策Aでは、次の図に示すように、バックアップHadoopクラスタからNetApp NFSストレージシステムにセカンダリバックアップが送信されるため、テープは必要ありません。
解決策 A の詳細なタスクは次のとおりです。
-
本番環境の Hadoop クラスタには、保護が必要な HDFS 内のお客様の分析データがあります。
-
HDFS を使用するバックアップ Hadoop クラスタは、データの中間的な場所として機能します。Just a Bunch of Disks （ JBOD ）は、本番環境の Hadoop クラスタとバックアップの Hadoop クラスタの両方で HDFS にストレージを提供する。
-
「 hadoop distcp – update – diff<hdfs1 ><hdfs2>` コマンド」を実行することで、 Hadoop 本番クラスタの HDFS からバックアップクラスタの HDFS へと Hadoop 本番データを保護します。
|
Hadoop スナップショットは、本番環境からバックアップ Hadoop クラスタへデータを保護するために使用されます。 |
-
NetApp ONTAP ストレージコントローラは、バックアップ Hadoop クラスタにプロビジョニングされる NFS エクスポートボリュームを提供します。
-
を実行します
Hadoop distcpコマンドMapReduceと複数のマッパーを活用して、分析データをバックアップHadoopクラスタからNFSに保護します。ネットアップストレージシステム上の NFS にデータを格納したあと、必要に応じて、ネットアップの Snapshot 、 SnapRestore 、および FlexClone テクノロジを使用して Hadoop データをバックアップ、リストア、および複製します。
|
|
Hadoop データは、 SnapMirror テクノロジを使用してクラウドやディザスタリカバリロケーションに保護できます。 |
解決策 A には、次のような利点があります。
-
Hadoop の本番データはバックアップクラスタから保護されます。
-
HDFS データは NFS を通じて保護されるため、クラウドやディザスタリカバリの場所を保護できます。
-
バックアップ処理をバックアップクラスタにオフロードすることでパフォーマンスを向上します。
-
手動でのテープ操作が不要になります
-
ネットアップのツールを使用してエンタープライズ管理機能を利用できます。
-
既存の環境への変更は最小限で済みます。
-
対費用効果の高い解決策です。
この解決策の欠点は、パフォーマンスを向上させるためにバックアップクラスタと追加のマッパが必要であることです。
お客様は最近、解決策 A を導入しました。シンプルさ、コスト、全体的なパフォーマンスが理由です。
この解決策では、 JBOD の代わりに ONTAP の SAN ディスクを使用できます。このオプションを選択すると、バックアップクラスタのストレージ負荷が ONTAP にオフロードされますが、問題となるのは SAN ファブリックスイッチが必要な場合です。
解決策 B
解決策BはNFSボリュームを本番用Hadoopクラスタに追加するため、次の図に示すように、バックアップHadoopクラスタは必要ありません。
解決策 B の詳細なタスクは次のとおりです。
-
NetApp ONTAP ストレージコントローラは、本番用 Hadoop クラスタに対して NFS エクスポートをプロビジョニングします。
Hadoopネイティブ
hadoop distcpコマンドは、Hadoopデータを本番用クラスタのHDFSからNFSに保護します。 -
ネットアップストレージシステム上の NFS にデータを格納したあと、 Snapshot 、 SnapRestore 、および FlexClone テクノロジを使用して、必要に応じて Hadoop データをバックアップ、リストア、および複製します。
解決策 B には次のような利点があります。
-
本番環境クラスタは、バックアップ解決策用に若干変更されるため、実装が簡単になり、インフラコストを削減できます。
-
バックアップ処理のためのバックアップクラスタは必要ありません。
-
HDFS の本番環境のデータは、 NFS データへの変換によって保護されます。
-
解決策では、ネットアップのツールを使用してエンタープライズ管理機能を実行できます。
この解決策の欠点は、本番クラスタに実装されており、本番クラスタに管理者タスクを追加できることです。
解決策 C
解決策 C では、次の図に示すように、 NetApp SAN ボリュームが HDFS ストレージの Hadoop 本番クラスタに直接プロビジョニングされます。
解決策 C の詳細な手順は次のとおりです。
-
NetApp ONTAP SAN ストレージは、 HDFS データストレージの本番用 Hadoop クラスタでプロビジョニングされます。
-
NetApp Snapshot テクノロジと SnapMirror テクノロジを使用して、本番用 Hadoop クラスタの HDFS データをバックアップします。
-
バックアップはストレージレイヤにあるため、 Snapshot コピーのバックアッププロセス中は Hadoop / Spark クラスタの本番環境でパフォーマンスが低下することはありません。
|
|
Snapshot テクノロジを使用すると、データのサイズに関係なく数秒で完了するバックアップを作成できます。 |
解決策 C には次のような利点があります。
-
スペース効率に優れたバックアップは、 Snapshot テクノロジを使用して作成できます。
-
ネットアップのツールを使用してエンタープライズ管理機能を利用できます。