クラウドファーストから
オブジェクトストレージへの保存
さあ次はデータを保管するオブジェクトストレージ部分じゃ。
このオブジェクトストレージを確実にバックアップできるかどうかも重要な部分じゃ。
AWSではS3、AzureではBlobと言われるサービスですよね。
実はデータを保管する場所というだけであまりよく、オブジェクトストレージが何かがよくわかっていないんですが…
オブジェクトストレージは大量の 非構造化データ
保存するためのデータ保管場所じゃ。
非構造化データ ってなんですか?
簡単に説明すると、構造化データはデータベースのデータのようにテーブル内に行と列があり、そのデータを後から分析などに再利用できるデータのことじゃ。そして非構造化データとはメール文やワード文章などの後から分析がしにくいデータのことをいう。ちなみにJsonなどの形式のファイルはkey-value型といいデータの分析などができるが非構造化データとして分類されている。
構造化データ
非構造化データ
でもそういうデータであればファイルサーバーに保存するのと
変わらないのではないでしょうか?
いいところに気が付いたな。確かにファイルサーバーなどでも代用はできる。
ただし、ファイルサーバーなどはコスト面でも拡張性の面でも不利なんじゃ。オブジェクトストレージはフォルダ階層を無くし、一般に検索性の高い拡張可能なメタデータとともに保存する。スケールについて言えば、オブジェクトストレージは数ペタバイトのサイズに拡大することが可能で、通常、データの配置に関する制約がないんじゃ。よってクラウドなどストレージの拡張性がうたわれているAmazon S3やAzure Blobストレージは広く採用されるようになっているんじゃ。また、可用性も高く、Amazon S3では99.999999999% の耐久性となるように設計されている。この耐久性レベルは、0.000000001% のオブジェクト平均年間予測喪失率に該当し、例えば、Amazon S3 に10,000,000のオブジェクトが格納されている場合、単一のオブジェクト損失が発生する予測平均発生率は、10,000年に1度じゃ。
ファイルサーバー
オブジェクトストレージ
すごく少ない発生の確立ですね。ではAWS S3などはバックアップの必要はないのではないでしょうか?
バックアップには障害に対する備えももちろんあるが、それ以外に人的ミスによる備えも大きいのは勉強したじゃろう。
あとはベンダーロックを回避する意味においてもS3データをバックアップすることは必要じゃ。
確かに前回の「バックアップを最初に学ぶ人が読む冊子!」の時にも人的ミスによるデータ復旧の考え方があることを学びましたね。
ベンダーロック回避とは具体的にAWS→Azureやオンプレなどにデータを移動できることを意味していますか?
そうじゃな。ベンダーロックを回避するには、いろんな仕組みを作らなければいけないが、まずはS3などのオブジェクトストレージについていえばデータを移行できる仕組みを用意しておくことが重要じゃ。
2020年6月現在ではAWSの利用率がNo.1であることは事実じゃ。一方で近年マイクロソフトのAzureがすごい勢いで追い上げてきていることも事実じゃ。クラウドのメリットは自由に簡単にかつ便利に利用できることじゃ。その時に一番コストパフォーマンスがよく使い勝手のいいクラウドベンダーにいつでも移れる仕組みを用意しておくことは非常に重要じゃ。
確かにそうですね。そういった意味でS3のデータを
バックアップできるメーカーを選ぶようにします。
守くん。ここは非常に重要なポイントじゃ。
メーカーの仕様ではオブジェクトストレージのバックアップは可能であるが、実際にオンプレミス環境に戻せないメーカーの製品も多数ある。またリストア可能な場合でも、非常に戻す手間が複雑なメーカーもある。慎重に確認することが重要じゃ。
クラウドバックアップは可能だがオンプレミスに戻せない場合
オンプレミスに戻す際に非常に手間がかかる場合
えーそうなんですか? 博士が言っているのは具体的に、AWSに行くならAMIに変換、そしてAzureならVHD、そしてクラウドからオンプレのVMwareに戻るならVMDKというように自由に変換できるという事でしょうか?
その通りじゃ。大分勉強の効果が出てきたようじゃな。
そうなんですね・・・各メーカーの仕様を確認した時に、多数のメーカーが
「色々なデータ変換が可能!」と書いているのをそのまま信じていました。
別にメーカーは嘘をついているわけではない。
ただ2020年6月現在では、まだ各メーカー色んな制限があったりする。
例えばクラウドへの変換は簡単だが、リストアの際はGUIではなくCLIで沢山のコマンドを打たないといけなかったり、初めに変換した際のVMDKに戻さないといけないなど、バックアップメーカー独自の制約がつく場合があるのが現状じゃ。特に戻る際に制限がつく場合が多いようじゃ。その辺も含めてクラウドへの移行は慎重に行わなければならない。
CLIでリストアしなくてはならない場合
リストアの際、一度VMDKに戻さなくてはならない場合
博士・・・結局どこのバックアップメーカーを選ぶのが正解なのでしょうか?
うん、なかなか難しい質問じゃ。これと言う答えはない。
何故なら100点のメーカーはないからじゃ。
例えば、バックアップファイルだけではバックアップサーバーが壊れた時に本番環境を戻す事が非常に複雑なメーカーもある。具体的にはカタログデータを最初にリストアするなど、手順が必要なメーカーがある。一方でカタログデータも必要なく、バックアップデータだけでスイスイ本番環境を戻せるメーカーもある。これだけ聞くと後者の方が優秀に思える。
バックアップサーバー破損に備えて準備が必要なメーカー
突然バックアップサーバーが破損しても問題ないメーカー
①あらかじめバックアップサーバー内部で保持している
 カタログデータをオブジェクトストレージにバックアップ
②バックアップサーバーが破損した際、オブジェクトストレージに保存
したカタログデータをバックアップサーバーに復旧
③クラウドのバックアップデータを 本番環境に移行
①②の過程が不要
③クラウドのバックアップデータを本番環境に移行
カタログデータとは?
バックアップの際、データの一部として、クラウドやテープに格納されるメタデータのこと。 バックアップデータ(チャンク形式)を復元する際、データを再構築するために必要な情報である。
Webサイトに例えると…
2020/07/01に
通販サイトAでログイン
したIDとPASS
フォームに入力したログ
(Cookie)があるため
すぐにログインできる
ただ〜し! 後者の場合はバックアップデータの内部にカタログデータも持っているために、重複排除率は前者のメーカーに比べて低くなる。
バックアップサーバー破損に備えて準備が必要なメーカー
突然バックアップサーバーが破損しても問題ないメーカー
重複排除
重複排除
うーん。単純にどの製品が一番いいとは一概に言えませんね。
そうじゃ。基本的に伝えたいことはこんなところだが、最後にクラウドをバックアップとして利用する場合も、クラウドをメインとして利用する場合にも覚えておいたほうがいいことを伝えよう。 レジューム機能 の有無じゃ。
これまたあまり聞いたことのない言葉ですね。
ほんとITの世界は奥が深いですね。
ははは!やっとわかってきたか。常に勉強じゃ。
レジューム機能は一般的なDRサイト構築時にも言える事で、回線が途中切れた場合の処理について、切れた場所からデータの再送ができる機能じゃ。
インターネット回線が途切れる事はよくある事じゃろ。
例えば監視カメラのデータなどの様に大きなファイルを転送中に途中で回線が切れた場合などに、回線が再接続した際にデータを初めから再転送をしたのでは非常に時間がかかって効率的ではない。レジューム機能があれば、切れた途中から再転送になるので、余分な時間がかからない。レジューム機能があるかどうかも重要な確認ポイントじゃ。
レジューム機能なし
レジューム機能あり
なるほど。他にはありますか?
オンプレとクラウドの管理画面が異なる
場合があるから注意が必要じゃ。
オンプレミス
クラウド
コマンド勉強
しなきゃ…
確かにそうですね。オンプレとクラウドで同じ管理画面なのは
管理者にとってメリットが非常に大きいと思います。
画面が異なると言葉の定義がズレたり、学習コストが2倍になりますからね。
そうじゃな。クラウド編で基本的なところはこんなもんじゃ。
えっ・・・
こんなにあってこれで基本的というのが気になりますが…
でも博士のおかげでだいぶ色んなことを考慮しなければいけないことがわかりました。どちらが正解かを選ぶのではなくどちらがよりお客様の環境に合っているかを選択する事が重要ですね。
でもこれを全部覚えてお客様に提案するのは大変ですね。
安心するんじゃ。2020年8月1日を以って30周年を迎えた ネットワールド ではこの辺を熟知したエキスパートが沢山おる。お客様先まで同行して、何がそのお客様にあっているかを相談にのってくれるから安心じゃ。
それもそうですね! いつもお世話になっているネットワールドに相談しよーっと。

pagetop