VMware環境の設計に欠かせないリファレンス アーキテクチャ

投稿日: 2019年8月11日 クライム
VMware

Reference Architectureとは？

リファレンス アーキテクチャ（reference architecture）とは、ごく簡単に言えば、IT環境のシステム構成を文書化したもので、諸々のハードウェア、ソフトウェアなど、何をどう組み合わせて、どう設定したのか、経験則にもとづく最善策を担当者が記録し、社内でその知識を共有するための文書です。言うなれば、システム構成・インフラ設定のベストプラクティス（best practice）です。

リファレンス アーキテクチャという用語は耳慣れなくても、同様のものは、詳しさに程度の差こそあれ、どこのITチームにも必ずあるのではないでしょうか。

しかし、その詳しさの程度はけっこう重要で、例えばVMwareの環境を構築するとき、インストール ガイドやサポート資料に傾倒し過ぎて、自社環境（あるいはサポートする顧客環境）の要件に合致していないければ意味がありません。要件とは、パフォーマンスやセキュリティはもちろん、予算も含めて、です。

そこで、重要な役割を成すのが、特定環境にカスタマイズされたリファレンス アーキテクチャです。

CPUのコア数と速度

たとえば、VMware環境の設計では、CPUの選択も重要です。ベンダーの好みよりも、ワークロードの要件を最優先に考えてCPUを選択すべきです。ワークロードやVMがトランザクション ベースなら、CPUソケットごとに多数のコアがあったほうが効率がよく、その一方、データベースのような集中型のワークロードなら、少ないコア数でより高速処理が可能なCPUが望ましいでしょう。トランザクションも、集中型のワークロードも両方対応すべきなら、コア数とコアスピードのバランスが重要になり、なおさら要件の見極めが不可欠になります。

ホスト ストレージの効率化

SANやNASを使用するときは、ローカルのストレージを軽視しがちです。実際には、ホストに使用するローカル ストレージは、環境全体のパフォーマンスを左右します。ローカル ストレージを用いる利点は、処理速度に加え、セキュリティ管理がしやすさも見逃せません。

RAID構成をともなうHDDやSSDなら、低いレイテンシで比較的高速のストレージで、あらゆるワークロードに柔軟に対応できますが、SAS接続のSSDがキャッシングに使われると速度が制限されます。

そこで、NVMeストレージでvSANを設定することもできますが、NVMeカードが故障すると（それが唯一のVMストレージの場合）データを失うので注意が必要です。

このように、求められるワークロードの処理要件も十分考慮し、決して見切り発車せずに、綿密なプランにもとづいてVMware環境を設定することが大切です。設計がしっかりしていれば、後々の業務拡大に柔軟に対応でき、拡張も容易になります。備えあれば憂いなし。リファレンス アーキテクチャあれば、サビ残なし（は飛躍しすぎかな）

AWS EBSスナップショットを S3にコピーしてストレージコストを節約する方法

投稿日: 2019年7月6日 クライム
AWS

Q: AWS S3にEBSスナップショットを保存する方法を教えてください。

最初に、基本となるEBSスナップショットのAmazon S3へのコピーメカニズムに対する非常に一般的な誤解が原因で、それ自体が誤って表現されていることが問題です。 EBSスナップショットは、実際にはデフォルトでAmazon S3に格納されていますが、ユーザーには見えないバケットで別のAWSインフラストラクチャに格納されています 。 すでにAWSのワークロードを管理している場合は、AWSのストレージ料金が非常に高くなる可能性があることをご存知でしょう。

多くのAWSユーザーが実際に探しているのは、EBSスナップショットをAmazon S3 オブジェクトストレージにコピーしてストレージ・コストを節約し、長期保存するためのソリューションです。 これからEBSスナップショットとは何か、 N2WS Backup＆Recovery を使用して簡単にS3にバックアップする方法 、およびストレージコストが劇的に低下する主な理由について説明します。

Amazon EBSスナップショットとは何ですか？

従来のデータセンターのほとんどのストレージ・アレイと同様に、EBSボリュームにもスナップショット機能があります。 EBSスナップショットはEBSボリュームのポイント・イン・タイムのコピーで、特定の時点におけるEBSボリュームの正確なイメージが格納されます。 EBSスナップショットに関するもう2つの重要な機能は次のとおりです。

●EBSスナップショットはブロック・レベルの増分バックアップです 。つまり、すべてのスナップショットは、最後のスナップショット以降に変更されたボリューム内のブロック（または領域）のみをコピーします。

●EBSスナップショットはコンテキストを意識したものです。つまり、EBSボリュームの最初のフルスナップショットを取得したときは、データを含むボリューム内の領域のみがコピーされます。 書き込まれなかったボリューム内の領域はコピーされないため、時間とストレージスペースを節約できます。

AWSは、EBSスナップショットを含むすべてのデータをAmazon Simple Storage Service（Amazon S3）に「遅延的に」保存します。 つまり、データは自動的にS3に保存されますが、Amazon S3インターフェイスを介してEBSスナップショットにアクセスすることはできません。 これは、それらが実際のEBSストレージとは別のインフラストラクチャに配置されているためです。前述したように、一般に公開されているバケットではありません。 EBSスナップショットの復元について説明するとき、 EBSスナップショットはブロックレベルのスナップショットであり、保存するデータの種類を認識していないため、EBSスナップショットへのきめ細かいアクセスは不可能です。 データを復元するには、いずれかのEBSスナップショットから新しいEBSボリュームを作成する必要があります。 新しいボリュームは、スナップショットが作成された最初のEBSボリュームの複製になります。

N2WSを使用してEBSスナップショットをAmazon S3バケットにコピーする方法

N2WS Backup＆Recovery 新機能には、 EBSスナップショットデータをAmazon S3バケットにコピーする機能が含まれています 。これにより、 長期保存期間とアーカイブコストを削減できます 。 新しいS3へのコピー機能を使用すると、1つのS3バケット内に複数のリポジトリを定義したり、S3でバックアップをリポジトリにコピーする頻度を定義したりできます。

それはどのように機能しますか？

N2WSがスナップショットをAmazon S3にコピーすると、実際に起きているのは、一時的なS3 ワーカー・インスタンスを起動してオブジェクトをS3に書き込むタスクを実行することです。 タスクが完了するとすぐに、ワーカー・インスタンスは終了します。 このように、N2WS Backup＆RecoveryはEBSスナップショットを取得し、それらを独自の形式（ .vbk）にエクスポートします。これは、Veeamがバックアップに使用するのとまったく同じファイル形式です。 S3でフルバックアップを再作成しているのではないことを知っておくことは重要です。実際には増分スナップショットを取得し、それらをAmazon S3内で増分的に保持しています。 ユーザーは自分のバックアップをAWSに復元するか、 Veeam Backup＆Replication 9.5 Update 4からその機能を使用してS3リポジトリからオンプレミスまたは他のパブリック・クラウドにバックアップを復元するかを選択できます。

また、クライムでは 「Veeam Backup for AWS」というAmazon EC2インスタンスをエージェントレスで簡単オンプレ、クラウドへ自由自在にバックアップ、リストア可能なソリューションも提供しています。

AWSのストレージコストはどのように影響を受けますか？

EC2バックアップソリューションでEBSスナップショットを使用している場合は、スナップショットの自動化および管理方法について心配するだけでなく、それらの保存コストを削減する方法も必要になります。 新しいリリース以降、N2WS Backup＆Recoveryを使用すると、AWSのストレージコストを最大40％削減できます。

EBSスナップショットをAmazon S3にアーカイブすることで、EBSスナップショットのストレージコストを大幅に削減できる手法は数多くあります。 良い例は、組織が数年間バックアップを維持するために規制順守要件を厳守することです。 その期間に必要なすべてのシステムをバックアップすることを検討すると、毎月のストレージコストは膨大になります。 さらに、復元の必要性があまりない場合は、これらすべてのバックアップを保存すると、オーバーヘッドが非常に大きくなる可能性があります。 理想的な解決策は、 これらのバックアップをAmazon S3に移動して、はるかに耐久性が高く安価になるようにしてから、必要に応じてそれらをバックアップしてリカバリすることです。

結論

AWS環境では、データの安全性を確保する責任がユーザにありますが 、AWSのワークロードを増やすにつれて効率を上げる方法も必要です。 N2WSは、高度なバックアップおよびリカバリ機能を最先端技術で提供します。 その「Amazon S3レポジトリへのコピー」機能により、バックアップに関連するストレージコストを削減しながら、自社のAWSへの展開に関して自動化、使いやすさ、およびスケーラビリティの向上を企業に提供できます。

タグ: , , , , ,

どうして時代はクラウド・ベースのストレージなのか？

投稿日: 2019年4月30日 クライム
クラウド・仮想インフラ

クラウドベースのバックアップにより、あらゆる規模の組織、特に中小企業（SMB)が、収益に大きな影響を与えることなく、増大するストレージ要求を克服することが可能になりました。

どこからでもあなたのデータにアクセス

クラウドベースのストレージの最大の利点は、アクセシビリティです。

クラウドにバックアップした後は、世界中のどこからでもデータにアクセスできます。 必要なのはインターネットに接続されたデバイスとログイン認証情報だけです。

追加ストレージが必要な場合は、それを簡単に購入

洗練したオンプレミスのバックアップ・インフラは、特に規模を拡大している場合は特にコストがかかります。

従来のバックアップでは、ストレージ容量はオンサイトのインフラストラクチャに制限されていました。

オンプレミスのバックアップ・インフラを拡張するには、追加のハードウェア（磁気テープやテープドライブなど）を購入し、より多くの人員を割り当てる（追加のリソースを管理するために）必要があります。

データをクラウドにバックアップするときに、より多くのストレージが必要な場合は、簡単に購入することができます 。それは通常は手頃な価格です。

そしてクラウドベースのストレージ・プロバイダは、すべての面倒を見てくれます。

クラウドベースのバックアップはオンプレミスのストレージ・オプションよりも安全

サイバーセキュリティの脅威が高まっています。

企業が拡大し進化し続けるにつれて、データ侵害が企業に影響を与える可能性を考慮する必要があります。データ損失は、特に小規模の企業にダメージを与えるにする可能性があります。

National Cyber​​ Security Allianceによると、データ漏洩から6か月以内にSMBの60％が廃業したという報告があります。

ユーザがバックアップを保存している場所で洪水やその他の自然災害が発生すると、テープが破損する可能性があります。テープが破壊されると、データは永久に失われます。

また、テープバックアップは、ロック（施錠）されている場合でも簡単に盗まれる可能性があります。

クラウドに保存されたデータは通常、24時間監視によって保護されています。

クラウドに転送されたデータもまた、高い耐久性と冗長性があり。ストレージの信頼性を高めるために、場合によっては別の場所に複製されています。

多くのクラウドベースのデータプロバイダは、データの保存と保護に関するデータ要件規制に準拠しています。

階層型ストレージがコスト削減に

それがストレージになると、コストは常に要因です。

クラウドベースのストレージがバックアップに関連するコストを軽減することができる一つ方法は、アクセシビリティに基づいてストレージを自動的に階層化することです。

すべてのデータが等しいわけではありません。 コストを節約するために、すぐに利用できる必要がない場合は、データを別保存することができます。

クラウドベースのストレージでは、経費を節約するためにバックアップを自動的に高価格層から低価格層に移行させることができ、長期保存に最適です。

クラウドベースのストレージを使用してビジネスデータをバックアップする場合は、どこからでもデータに簡単にアクセスできるようにし、安全なバックアップを保ち、コストを削減します。

タグ: ,

AWSバックアップ保持ポリシー：3-2-1バックアップルール [N2WS Backup & Recovery]

投稿日: 2019年4月28日 クライム
AWS クラウド・仮想インフラ ディザスタ・リカバリ

「データが大事なら、バックアップしろ」は、誰もが経験上知っているはずの鉄則です。そして、バックアップされたデータは、以前は物理メディアに保存されてきました。ハードドライブ、NAS（ネットワークHDD）、テープなどです。その後、クラウドプロバイダが最低99.5%の可用性と、ギガバイト単位で低価格のストレージサービスを提供するようになってからは、もっぱらクラウドがバックアップ保存先の主流になりました。

システムを正しく、継続的にバックアップすることの重要性は、誰もが認めるところです。データが突然失われる理由には、人的エラー、ハードウェアの不備、地域的な仮想環境の停電（稀ですが、起こり得ます）、自然災害（洪水、火事、地震など）、マルウェアやハッカーによる攻撃など、枚挙に暇がありません。だからこそ、業務上不可欠なシステムの適正なバックアップ戦略がとても大切になります。データのバックアップには以下のような戦略があります。

  • リモートバックアップ：すべてのバックアップをオフサイトに保存
  • クラウドストレージ：クラウドストレージ会社を利用してデータを保存
  • 3-2-1ルール：複数のバックアップコピーを異なる場所に保存

本稿では、3-2-1バックアップルールをAWS環境にどのように適用するかを解説し、そのバックアップ戦略を準備するため、さらにはバックアップを的確に確保するためのツールを紹介します。

3-2-1バックアップルールとは？

3-2-1バックアップルールとはバックアップを安全に保つための戦略です。3-2-1は以下を意味します。

  • 3：重要データは必ず3件用意（主要データ＋2つのバックアップ）
  • 2：そのうち2つは異なるストレージ媒体に保存
  • 1：そのうち1つはオフサイトに保存

データのバックアップは1件だけでは十分ではありません。そのバックアップが一か所に保存され、その場所に問題が生じてデータがすべて失われた場合、そのデータは二度と元には戻りません。もし、複数のバックアップを取っていたら、それを同時に失う可能性は減ります。それが、3件のバックアップ保存が奨励される理由です。

ストレージ媒体も壊れる危険性があるので、業務環境以外に複数のタイプの保存先を確保する必要があります。データのコピーは2件を2種類のストレージ媒体に保存すべきです。例えば、ネットワークの共有領域、NAS、テープ、光学ドライブなどです。さらにセキュリティを高めるために、コピーの1つはオフサイトに保存すべきです。外付けのハードドライブに保存して、それを安全な場所（金庫など）に保管するか、あるいはクラウドプロバイダに預ける選択肢があります。

さらに、もう一段階、バックアップ保存先の物理デバイスのセキュリティを高めるには、ハードドライブのファイルシステムを暗号化するか、あるいは独自の暗号化システムを備えたハードドライブに保存します。それにより、不正なアクセスからバックアップの安全を守ることができます。例えば、Linuxシステムでは、LUKSによってファイルシステムを暗号化できます。LUKSで暗号化されたファイルシステム上のデータには、パスフレーズを知っているか、アクセスを承認する証明書を持っていないとアクセスできません。Windowsシステムなら、BitLockerでファイルシステムを暗号化できます。

AWSでの3-2-1バックアップルール

N2WS Backup & Recoveryでは、EC2（Elastic Compute Cloud）インスタンスをはじめ、RDS（Relational Database Service）、EBS（Elastic Block Store）、RedShiftやAurora、さらにDynamoDBなどのデータベースをバックアップ保存できます。任意の期間バックアップを保存するように設定でき、さらに重要な点は、別の場所、別のアカウントにバックアップをコピーできることです。バックアップポリシーのコンフィギュレーション時に、バックアップを保存したいリージョンを指定するだけで、指定された場所に自動的にバックアップがコピーされます。

では、N2WS Backup & Recovery を用いて3-2-1バックアップルールをAWSに適用するには、どうすればよいでしょうか？

まず、バックアップしたいデータに対するポリシーを設定します。このポリシーは、別の場所か別のアカウントに保存するのが得策です。そして、対象データを異なる2つの媒体に保存するために、EBSスナップショットをオンプレミスか他のパブリッククラウドプロバイダに、N2WSとVeeam Backup & Replicationを用いてコピーする必要があります。これにより、データが3版作成されます。つまり、元のデータと2件のバックアップが作成され、バックアップのうちの1件は別のAWSリージョンかアカウント、もう1件はオフサイトに保存されます。これは、ありとあらゆる不測の事態に万全に備え、業務に滞りを生じさせることのない鉄壁のアプローチです。

N2WS Backup & Recovery 2.4の新機能

N2WS Backup & Recovery 2.4はAmazon EBSスナップショットのデカップリングとN2WS対応のS3リポジトリをサポートします。バージョン2.4の新機能は次のとおりです。

  • スナップショットをAmazon S3にアーカイブ：保持期間の長期化を回避し、アーカイブ費用を削減 → バックアップデータ保管コストを全体で40%節約できます。
  • VPCキャプチャー&クローン：サブネット、セキュリティグループ、ルーティングテーブルといったVPC（仮想プライベートクラウド）の各種設定をキャプチャーし、他のリージョンにコピーします。Amazonインフラストラクチャの中枢部ともいえる重要なコンフィギュレーションを他のリージョンに手作業で設定する必要がなくなります。
  • RESTful APIの強化：N2WSと通信する独自のアプリケーションを構築し、それを通じて、業務上不可欠なデータのバックアップを実行できます。
  • アカウント間をまたがる増分バックアップ：バックアップの変更部分のみがキャプチャーされるので、ストレージが効率的に使用され、コスト削減、バックアップおよびリストアの高速化につながります。

Veeam Backup & Replication 9.5 Update 4の新機能

Veeam Availability Suiteに含まれるVeeam Backup & Replicationを利用した3-2-1バックアップルールの適用については、Veeamブログに詳しく説明されています。ここでは、Veeam Backup & Replication 9.5 Update 4で提供される新機能に焦点を当てます。主な機能は次のとおりです。

  • Veeam Cloud Tierによる独自のオブジェクトストレージ：Veeam Cloud Tierは拡張性に優れたバックアップリポジトリで、データ長期保存を無制限に許容します。Amazon S3、Azure Blob Storage、IBM Cloud Object Storageなど、様々なクラウドプロバイダに対するオブジェクトストレージサービスに使用できます。AES-256にもとづくサーバーサイドの暗号化も任意で利用可能です。
  • 特定ベンダーに縛られない柔軟なリストア：アーカイブされたバックアップはすべて、いずれの時点（ポイントインタイム）においてもインポートやリストアが可能です。
  • ディスクスペースの効率利用：バックアップファイルは永久増分方式で保管されます。複数の完全バックアップ間での重複保存が避けられ、ストレージコストが削減されます。
  • 帯域幅の効率利用：オブジェクトストアリポジトリからのリストア時には、オブジェクトストレージから全ブロックを取得するのではなく、直近のバックアップファイルからのみブロックを読み込みます。出力トラフィックが最小限に抑えられ、リストアコストが削減されます。
  • 外部依存のない自己完結性：保管されたバックアップに対して、外部のカタログやメタデータが必要になることはありません。そのため、オンプレミスや他のクラウドプロバイダにバックアップをインポートすることができます。
  • コスト削減：Veeamはオフロードされたバックアップに対し、二次ストレージプロバイダが行うようなテラバイトごとのサブスクリプション課金を行いません。
  • 透明性：バックアップをオブジェクトストレージに保存しても、すべてのVeeam機能からアクセス可能な透明性が保たれます。バックアップはオブジェクトストレージからいつでもそのままリストアでき、ステージングを通して前処理する必要はありません。

まとめ

適正なバックアップ戦略を持つことは非常に重要です。データを失えば、業務が滞る危険はもちろんのこと、業務全体を停止しなければならなくなる危険性もあります。3-2-1バックアップルールを施行すれば、常にデータのコピーを余分に備えられ、不慮の事態にもデータを失うようなことはありません。この余剰コピーがあるからこそ、データバックアップのあらゆる戦略の中でも、3-2-1バックアップルールは最高の信頼性が証明されています。

クラウドに関して言えば、データを物理デバイスに保管するためのハードルは多少高くなります。データにはインターネット経由以外に完全なアクセスがあるわけではないので、バックアップの複雑化は避けられません。だからこそ、N2WS Backup & Recoveryのようなツールの活用が重要になります。インフラストラクチャをクラウドにバックアップし、それを保護する手段として、N2WS Backup & Recoveryは格好のツールと言えます。前述のとおり、データをオフサイトにバックアップすることもでき、最低1件の適正なバックアップがいつでもリストア可能な状態で常に準備されます。ただし、たとえバックアップが完璧でも、災害復旧プランのテストは2、3か月に1度は行い、リカバリプロセスが正しく機能するかどうかの確認は怠るべきではありません。

N2WS Backup & Recovery の無料トライアル

タグ: , , ,

中堅中小企業(SMB)での一般的なバックアップ・スケジュール手法は？

投稿日: 2019年3月9日 クライム
クラウド・仮想インフラ ディザスタ・リカバリ

特に一般的なものはありませんが、スケジューリングに関して正しいアプローチはあります。

ミッション・クリティカルなデータを保護する

●インフラストラクチャの問題点を見つけ出しててください。 ドメイン・コントローラとオンプレミスのActive Directoryがありますか？  フェイルした場合、どのユーザーも自分のマシンにログオンできなくなります。 これらの問題点をリストして保護してください。
●ミッションクリティカルなデータベースとファイルを保護します。 ローカルおよびオフサイトのデータ・ストレージにすべての運用ファイル、データベース、およびアプリケーションのバックアップを作成します。
●ミッションクリティカルなデータ用のバージョンを作成します。 最新バージョンが破損している場合 – 前のバージョンに戻すことができます。 いくつかのデータを失うでしょう、しかしそれの全部ではありません。
●データの変更頻度を確認してください。経理報告は月に一度変更でしょう。 SQLデータベース – 10分に1回 でしょう。データセットごとに異なるバックアップ計画を作成し、必要な頻度で使用してください。

帯域幅使用量のバランス

●勤務時間内に大きなデータセットのバックアップをスケジュールしないでください。 ユーザーは満足できず、データセットは時間内にアップロードされません。

●通常、ユーザーファイルの増分バックアップは日中に実行できます。 ただし、バックアップには最大スピードの上限を設定することをお勧めします。 それによって、バックアップ・ソフトウェアは帯域幅を最大限にすることはありません。
●日々のフルバックアップは夜中に、週毎は週末に実行します。
計画は最初に：
計画は最初にバックアップに関してすべてを計画し、その計画を文書化してから、バックアップ手順を開始します。多くの種類のデータ、そのデータのユーザー、データベース、およびバックアップが必要な施設があります。 計画を立てていなくても、スケジュールされたバックアップが多少でもあれば、最終的にそれらのことを忘れてしまう可能性があります。

正しいツールを利用して：
このブログの前半で述べたことはすべてデータの安全性の基礎となります。 適切な計画を立てれば、適切なツールを使用できるはずです。 バックアップのスケジュールと保存に関して可能な限り柔軟なツールはあります。

このCloudBerry Backupのバックアップ・スケジューラは、バックアップ計画ウィザードのステップとして提供され、以前のバックアップ計画を編集するときにも使用できます。

基本的なスケジュール設定に加えて、定期的なバックアップジョブを構成することもできます。これは、中小企業やスタートアップ環境に最適なソリューションです。

通常のフルバックアップと稼働週中に発生する一連の増分バックアップを設定することで、大規模な災害、ユーザーのミス、またはサーバーのクラッシュが発生した後でも、企業はデータを正常に復元できます。

SMB用のVMwareのvSphereとマイクロソフトのHyper-Vの仮想マシン（VM)のDRツールとしてVeeam Essentialsがあります。WindowsとLinuxの物理サーバ用DRツールとしてVeeam Agentがあります。

スモールビジネスのバックアップスケジュールに関するいくつかのヒント：

バックアップスケジュールはユーザを100%保護するものではありません。 しかしバックアップ戦略を改善するのに役立つヒントがいくつかあります。

●エラーが発生せずに復元できることを確認するために、直近で行われたバックアップの整合性チェックを必ず行ってください。CloudBerry Backupには、ストレージ容量を評価し、ストレージ内外のファイルのMD5ハッシュを比較するのに役立つ「Consistency Check」機能があります。
●災害をエミュレートし、データを復元することでDR（災害復旧）訓練を実行します。
これにより、すべてのシステムが完全に機能し、目標復旧時点（RPO）と目標復旧時間（RTO）がビジネスニーズを満たしていることを確認できます。
●少なくとも3つのバックアップコピーを作成します。例えば、ローカルストレージデバイス用に2つ、3つ目にAmazon S3などのオフサイトストレージ用です。
●サーバーをすべてリストし、それぞれの正確な場所を書き留めておきます。そうすれば、チームは災害の際に相談することができます。
●起こりうる災害ごとに回復のためのチェックリストと行動計画を作成してください。これは、話し合いではなくプロセスに集中するのに役立ちます。
●所有する各IT機器サプライヤの電話番号を書き留めてください。 ノートが災害に見舞われないようにしてください。 例：重要な書類と磁気テープは耐火性と防水性のある金庫に保管するのが良いでしょう。

結論

中小企業のための最良のバックアップスケジュールは、あなたの得意範囲、許容できるRPOとRTO、サーバーの数とデータタイプによって異なります。 上記のすべての点を要約すると、いくつかの基本的な規則を推定できます。

●リサーチとしっかりしたロジックに基づいて努力する
●暗記するのではなく、計画を文書化する
●ツールを使用してバックアップ計画をスケジュールし、一貫性を管理する

中小企業のためのバックアップ戦略を計画するとき、それらを覚えておけばユーザ・データは常に安全になるでしょう。

タグ: , , , , , , , , ,

2/17開催Webセミナー「Windows 2008サポート延長のために。Azure移行のことはじめ」録画

投稿日: 2019年2月20日 クライム
Azure クラウド・仮想インフラ

現在も現役で使用されているユーザーも多いであろうWindows Server 2008/R2、SQL Server 2008/R2の延長サポートも終了まで1年（Windows 2008/R2は2020年1月まで、SQL 2008/R2は2019年7月まで）を切りました。

期限までにバージョンアップするか、有償のカスタム延長サポートを購入するか、はたまたサポートがないことを承知で使い続けるかを判断する必要がありましたが、2018年7月に新しい選択肢が追加されました。

Windows Server 2008/R2、SQL Server 2008/R2をAzureへ移行することで、さらに3年間、セキュリティアップデートを無償で受け取ることができるようになります。

本セミナーでは、3年間の追加延長サポートを受けるために、VMware、Hyper-V上に構築されたWindows Server 2008/R2、SQL Server 2008/R2を、Azureへ移行するための手法についてご紹介します。

Zertoとは:  VMwareやHyper-V上の仮想マシンを、たとえ異種間であってもVMware/Hyper-Vへレプリケーションすることができます。また、各ハイパーバイザーからAWS環境へのレプリケーションも行なえます。

タグ: ,

AWS共有責任モデルとバックアップの必要性 [N2WS Backup & Recovery]

投稿日: 2019年1月4日 クライム
AWS クラウド・仮想インフラ

AWS上に存在するデータとワークロードを定期的にバックアップする必要があります。
理由は以下の通りです。

Amazon Web Services（AWS）クラウドコンピューティングには、従来のオンサイトインフラストラクチャモデルと比べて、利便性、スケーラビリティ、コスト、セキュリティなどの多くのメリットがあります。

あなたは「クラウドを利用したサービス」企業で、Amazon Cloudが提供する堅牢性とスケーラビリティを活用しています。

残念なことに、多くの企業は、追加のバックアップと災害復旧が必要であることを認識していません。

彼らは、S3のようなAmazonのサービスは耐久性があり、冗長化され障害、エラー、停電またはセキュリティ攻撃によるダウンタイムのリスクを軽減すると想定しています。しかし、これは非常に危険な考えであり、実際には間違っているとここでは説明しています。

クラウド環境のデータバックアップとセキュリティは不可欠であり、AWSではなくあなた自身に責任があります。
AWSの責任共有モデルは、「クラウドのセキュリティ」と「クラウドのセキュリティ」の詳細を共有しています。

「クラウド」自体はAWSによって保護されていますが、そのクラウド内のすべてがあなたの責任です。

セキュリティとコンプライアンスは、AWSと顧客の共通の責任です。

クラウドコンピューティングとAWSは、企業がデータを管理および格納する方法を変え、物理的なデータセンターやインフラストラクチャの維持に伴う操作負担を軽減していますが、クラウド内のすべてのセキュリティを展開、設定、および維持する責任があります。

AWS共有責任モデルビデオは、Amazonがワークロードやその他の資産を保護する機能を提供するさまざまなサービスとインフラストラクチャを担当していることをさらに説明しています。

AWSサービスは、サービスが動作している施設の物理的なセキュリティを操作、管理、および制御します。これにより、AWSの顧客はインフラストラクチャの問題を解消することができ、バックアップ電源やサーバルームの温度について考える必要がなくなりました。コアビジネスの管理に専念し、データセンター設備の管理をAWSのプロに委ねることができます。

AWSの顧客は、クラウドデータの可用性と完全性を完全に保護するために利用するAmazonサービスを選択することで、最終的な責任を負う必要があります。また、そのデータを保護するために、組織の特定の要件（RTOやRPOなど）を確実に満たす必要があります。たとえば、AWSの顧客はパッチや更新の実装にはこまめに確認するかもしれません。しかし、セキュリティグループ、IAM、またはクロスリージョンディザスタリカバリを構成することに関してはあまり意識していないことがあります。これがバックアップやセキュリティの大きな問題となります。

AWSの顧客が誤ってバックアップやコピーを持たずにワークロードを終了した場合、AWSは責任を負いません。利用社は、AWSがすべてのワークロードのバックアップコピーを作成したと仮定するべきではありません。共有責任モデルは、プラットフォーム、オペレーティングシステム、およびセキュリティ設定とともにAWSの顧客データがすべて顧客責任であることを明示しています。

NetflixやSalesforceのような大規模な企業では、ヒューマンエラーに加えて、ハードウェアの大規模な障害が発生していますが、バックアップの追加ソリューションを使用してダウンタイムを減らすことができました。適切なバックアップを適切に実行することで、悪意のある攻撃によるセキュリティ上の脅威が完全に阻止されています。

AWSの責任の一部には、クラウドのセキュリティが含まれます。顧客は、クラウド内のデータのセキュリティを担当します。AWSは、非常に低い障害率の耐久性のあるインフラストラクチャを提供します。AWSには、障害発生時にそのデータを保護するために必要なツールも用意されています。

これらのツールには：

  • EBSスナップショット（ブロックレベルの増分バックアップ）
  • リージョン
  • アベイラビリティゾーン
  • API
  • CLIs
  • ラムダスクリプトによる自動化

AWSの顧客は、EBSボリュームのスナップショットバックアップを作成することで復元力を確保できます。
S3に対してスナップショットのような形式で保存され、可用性が高くなります。これは、誤って終了したワークロードを非常に迅速に（30秒以内に）回復できることを意味します。スナップショットバックアップが定期的に行われていることを確認することは、上記の画像の共有責任モデルの青い部分にあり、青はあなたです！

ラムダスクリプトとAWS CLIおよびAPIを使用してスナップショットバックアップを自動化できます。または、弊社お問い合わせフォームより評価版を申し込んでいただくことで、カスタムスクリプトを使用することなく簡単にバックアップを行うことができます。
AWSはスナップショットやAWS APIを含むAWSが提供するネイティブツールを活用して、停止、障害、事故からAWSデータとワークロードを保護します。N2WSを選択すると、AWS用に選択されたバックアップとDRソリューションが利用できます。30秒で停止、障害、および事故から復旧でき、バックアップを作成する必要はありません。
また、レポート、監査、ダッシュボード、アラートなど、必要な機能を多く追加しています。

したがって、システム担当者であれば、AWSインフラストラクチャに最適な保護ソリューションを選択したいと考えています。バックアップとDRのために選択するものは、責任を無視することを選択しないでください。
上記の AWS責任モデルの青い部分は顧客の責任です。青はあなたです！

AWSのワークロードを簡単に保護できるCPMの詳細については、こちらよりお問い合わせください。

 

タグ: , ,

ストレージスナップショットは従来のバックアップの代わりになるのか？

投稿日: 2018年10月29日 クライム
VMware クラウド・仮想インフラ

ストレージスナップショットは、2つの異なる方法で作成できます。

最初の方法は差分スナップショットと呼ばれます。 このタイプのスナップショットの背後にある基本的な考え方は、スナップショットが作成されると、システムが実際に差分ディスクを作成するということです。
その時点から、すべての書き込み操作は、プライマリストレージではなく差分ディスクに向けられます。
プライマリストレージが変更されないようにして、必要に応じてシステムを元の状態に戻すことができます。

ポインタベースのスナップショットは新しいタイプのスナップショットであり、差分ディスクスナップショットとほぼ同じようにパフォーマンスに影響を与えません。ポインタベースのスナップショットの背後にある基本的な考え方は、スナップショット作成ソフトウェアが各ストレージブロックにポインタを割り当てることです。
ファイルが変更されると、そのファイルに関連付けられた記憶域ブロックは上書きされません。
代わりに、新しいストレージブロックが作成され、ポインタが新しいストレージブロックを指すように更新されます。ロールバックが必要な場合、ソフトウェアは特定の時点で使用されたストレージブロックを特定し、それらのストレージブロックを使用してシステムをロールバックすることができます。

第一世代のストレージスナップショットソリューションは、バックアップの代替品にはなりませんでした。
最新のスナップショットソリューションは、データを保護するための方法という点に限り、バックアップの代替品として使用できますが、あくまでスナップショットはデータレプリカとは異なります。
今日の技術では、数テラバイトのボリュームのコピーを数秒で作成することはほとんど不可能です。
ストレージスナップショットは、データの真のコピーを作成していません。
したがって、スナップショットソリューションを従来のバックアップの真の代替手段にするためには、スナップショットと元のデータの両方を保護する方法が必要です。 通常、これはデータとスナップショットをミラーリングされた場所にレプリケートすることを意味します。

加えて、ストレージスナップショットのみを使用してファイル単位のリストアを実施する場合、
VMに一時ボリュームを作成、戻したいファイルが存在する世代のストレージスナップショットを手動で検索し、ストレージスナップショット内のVirtual Volumeを作成した一時ボリュームへコピー、
ファイルを検索しリストアを実施する必要があるため、非常に手間がかかります。

このストレージスナップショットと連携し、高速かつ確実にバックアップを行うソフトとして、
クライムが取り扱っている Veeam Backup & Replicationがあります。
Veeamでは、ストレージスナップショットと連携し、仮想マシンへの負荷を最大限に抑えてのバックアップや、Veeamからアプリケーションレベルの静止点を作成したストレージスナップショットを、2次サイトのストレージにコピー、また復旧手段も豊富でファイル単位のリストアやインスタントVMリカバリなど、
多くの連携を単一コンソールより提供しています。

下記ベンダーのストレージをお使いの場合には、是非ともVeeamと連携したバックアップをお試しください。
・Cisco HyperFlex
・Dell EMC VNX, VNX2, VNXe, Unity
・HPE 3PAR StoreServ
・HPE StoreVirtual (LeftHand / P4000 series), StoreVirtual VSA
・NetApp FAS/AFF, FlexArray (V-Series), ONTAP Edge/Select/Cloud VSA, IBM N series (FAS OEM)
・Nimble Storage AF-Series, CS-Series
・IBM Spectrum Virtualize
・INFINIDAT Infinibox F-series
・Pure Storage FlashArray
・Huawei OceanStor

タグ: , , , ,

VMworld2018 in ラスベガス レポート①

投稿日: 2018年9月23日 クライム
AWS VMware vSphere クラウド・仮想インフラ

ラスベガスで8/26～8/30に開催されたVMworld2018の概要をご紹介いたします。
VMWorldは今回で15回目となり、世界各国から2万人以上、日本からはおよそ380名が参加しました。
今回のテーマは “Possible begins with you”でした。

ジェネラルセッションの様子です。
今回はプライベートクラウドと併せて用途別に様々なパブリッククラウドを使用する、
『マルチクラウド』という単語がよく聞こえてきました。

●主な発表内容

・Amazon RDS on VMware
オンプレミスのVMware環境でもAmazon RDSが使用可能となります。
RDSの特徴ある、拡張性や可用性、また保守(パッチ適用など)不要など、
運用管理面で大きなメリットがありそうです。
Oracle/SQL Server/PostgreSQL/MySQL/MariaDBのDBが利用できる予定です。

・VMware Cloud on AWS (大阪リージョン対応)
既にリリースが発表されており、2018Q4での東京リージョンに加えて、
2019Q2に大阪リージョンも対応すると発表がありました。

・CloudHealth Technologiesの買収を発表
AWS/Azure/Google Cloud Platformなど様々なパブリッククラウドを
一元管理可能なCloudHealthの買収が発表されました。
リソースや使用量、パフォーマンスを一元的に管理できるようになったことで、
用途別に様々なクラウドの使い分けが可能になりそうです。

・ESXi on 64 bit Arm
ARM系プロセッサのサポートをこれから組み込みOEMベンダとの協業して、
調査、研究を進めていくとのことでした。

・Project Magna
機械学習をベースにデータセンタの自律的な稼働を実現するためのプロジェクトを発表。データセンタ環境での強化学習の実現を通じて、より優れたパフォーマンスと効率性を実現を目指すとのことでした。

・Project Concord
ブロックチェーン技術を活用してエンタープライズ向け分散型インフラストラクチャの実現。現在オープンソースプロジェクトとして利用可能です。

タグ:

VMworld2018 in ラスベガス レポート② Veeamセッション

投稿日: クライム
VMware

VMworld2018のVeeamのセッションの概要です。
次にリリース予定のUpdate 4で追加予定機能が紹介がメインでした。

NASのバックアップ機能はUpdate4には入らず来年以降となりそうです。

 

・Update4追加予定機能①『Veeam Cloud  Achieve』
古いバックアップをクラウドやオブジェクトストレージへの保存が容易になります。
年次・月次でのバックアップ保存が必要でバックアップ保存領域が足りない場合に便利な機能です。

・Update4追加予定機能②『Veeam DataLabs Staged＆ SecureRestores』
Veeamで作成した隔離環境に一度リストアをして、ウィルスチェックやGDPR対策で
個人情報を削除後に本番環境へ安全にリストアが出来る機能となります。

・Update4追加予定機能③『Veeam Intelligent Diagnostics』
Veeam ONEを使用してVeeam Backup＆Replicationのログから
問題となりそうな事象を検知した場合、に該当事象のKBを通知する機能です。

・Update4追加予定機能④『Veeam Cloud Mobility&External Repository』
現在、AzureへのDirect Restore機能を利用可能ですが、
Update 4では追加してAWSへのDirect Restoreが可能となります。

タグ:

AWS EC2のバックアップはなぜ必要になるのか？ N2WS Cloud Protection Managerで確実なバックアップ

投稿日: 2018年7月13日 クライム
AWS クラウド・仮想インフラ

EC2のバックアップソリューションをあなたは本当に必要としますか？多くのユーザーはサービスとしてサーバーを手に入れると、サーバーの管理も全て含まれていると決め込みます。従来のデータセンターと比較すると、AWSはハードウェアの問題をすべて対処します。つまり、ハードウェアの障害によってデータが失われることはありません。ただし、ハードウェア以外のデータ損失シナリオは対処されません：

  • Cloud Protection Managerを使用する：EBSボリュームが停止した後破損しているケースがあります。これは非常に稀なケースですが、重要な運用データをEBSボリュームに格納する場合、このリスクを冒すことは望ましくありません。
  • ダウンタイムを最小限に抑える：クラウドが停止すると、停止が確定して通常の操作が再開するまでに時間がかかることがあります。別の可用性ゾーンまたは別の地域での操作を再開してダウンタイムを最小限に抑えたい場合は、EC2バックアップソリューションが役立ちます。これに対する最適な答えは高可用性ソリューションであることは事実です。ただし、CPMのようなスナップショットベースのEC2バックアップソリューションは、数分で別の場所でEC2のインスタンスとデータを復旧するのに役立ちます。
  • ソフトウェアの誤動作の処理：ソフトウェアの誤動作の結果としての論理的なデータ損失は、永久的になる可能性があります。どこかでソフトウェア製品のスクリプトのバグがEBSボリュームからデータを削除する可能性があります。このような場合、EC2バックアップソリューションを使用すると、それらのボリュームの最新の一貫したイメージにロールバックすることができます。
  • ヒューマンエラー：ヒューマンエラーは時々永久的なデータ損失を引き起こすことがあります。ITに乏しい担当者が更新操作を実行しなければならず、ディスクが削除されたり、データベースが破損したりします。オンプレミスやクラウドサーバー上では、誰にでも起きる事です。データ損失が発生する前の特定の時点に戻すことができるようにするには、EC2バックアップソリューションが必要です。
  • 悪意のある攻撃の対策：EC2上で実行されているアプリケーションの多くは、インターネットに接続されています。SaaS製品、インターネットホスティング、ゲームホスティングのいずれかになります。あらゆる種類の攻撃を防ぐための対策を講じています。しかし、100％防ぎ切れるわけではありません。常にサーバーが最新の動く状態に戻る手段が必要です。
  • 規制目的：多くの場合、一定の期間データの履歴を保存するように強制する規制があります。スナップショットベースのソリューションは、このような目的のための典型的なツールではありませんが、バックアップソリューションが必要です。

要約すると、EC2は高いデータ復旧と非常に高い稼働時間を保証しますが、データ損失とダウンタイムのすべてのシナリオを確実にカバーするためには、EC2バックアップソリューションが必要です。

EC2のバックアップソリューションCloud Protection Manager(CPM)の詳細については、こちらよりお問い合わせください。

タグ:

Nutanix .NEXT Conference 2018 レポート

投稿日: 2018年5月11日 クライム
クラウド・仮想インフラ

Nutanix .NEXT Conference 2018が米国ニューオーリンズで5月8日から10日まで開催されました。　https://www.nutanix.com/next/

参加する機会がありましたので、新製品の概要等をご紹介します。

まず、Multi Cloud、Enterprise Cloud OS、Hybrid of Multi Cloud等の言葉が強調されていたと感じました。

■Nutanix Beam（ビーム）
マルチ＆ハイブリッドクラウドをまたがったコストとリソースの最適化と可視化.
Azure, Google Cloud, AWS, Nutanix
PCI-DSS・HIPAA・CIS等のセキュリティ基準にに準拠しているかをワンクリックで確認
Nutanix BeamはSaaSとしての提供:　https://www.nutanix.jp/products/beam/

■NutanixのOSS(Object Storage Service)のサポート開始

■FLOW/Netsil: VMwareのNSX対抗か

Nutanixのネットワーク周りはFLOWという名前に変更
可視化やマイクロセグメンテーション、サービスチェイニング等
将来的には先日買収したNetsilの機能も組み込んでより強力な可視化を提供
アプリケーション観点でのグルーピングやディープパケットインスペクションに
よる統計など

 

■Xi(ザイ)Cloud Service

数クリックでDR環境の配備が出来る
Seamless Extenshion,Failover,Failback, Testをアピール

■Multi-Cloud App Mobility

クラウドからNutanixへのマイグレーション。
CBT(Change Block Tracking)により最小のダウンタイムで移行完了

 

■　Veeam社からNutanix AVHとの統合サポートについての紹介もありました。

(注)筆者はNutanix製品に関しての知識があまりありません。説明不足はご容赦ください。

タグ: , , , ,

インターネット経由で別PCへのバックアップ方法　（VPN経由）

投稿日: 2018年4月26日 クライム
クラウド・仮想インフラ ディザスタ・リカバリ

最初に今回のVPNベースのリモート・バックアップ・リポジトリを作成するために必要なチェック・リストを以下に示します。

1.  2台のWindowsシステムが、別々の場所にある。仮想環境か物理環境のどちらかで。今回はWindows10をクライアント・サイドの例として使用。
2. VPNサーバと使用するリモートのリポジトリ・システム用に外部スタティックIPで、ユーザはインターネット上で直接このシステムに接続可能。
3．VPNコンフィグレーションでネットワーク・アダプタ設定変更とバックグラウンド・システム・サービスを稼働させることで両システムに管理者権限を有します。
4. SoftEther VPNのサーバとクライアントの各ディストリビューション・ソフト（今回はVPNにSoftEther VPNを使用）
5.CloudBerry Backupを活用

PCリモートPCへのVPN接続設定

リモートPCへのVPN接続設定に関するサーバ設定、クライアント設定はSoftEther VPNドキュメント を参照ください。(次からはリモートPCへのVPN接続の設定がSoftEther VPNを使用して終わった後の内容です。）

リモート共有フォルダへのアックアップ方法：

Windows Network Sharingはユーザがローカル・ネットワーク上でコンピュータへのアクセスを許す複雑なサーボス・セットです。制限のあるVPNネットワークではDNS や NetBIOS ネームの代わりにIP アドレスの使用を推奨します。このアプローチは共有パフォーマンスと接続安定度を向上させます。

CloudBerry Backupで直接の共有フォルダをマップすることもできますが、最初は特定ホルダの共有が必要です。

●リモートPCに接続し、Windows Explorerをオープン。CloudBerry バックアップを保存するホルダを作成し、「プロパティ」を選択。
●「Sharing」タブを選択し、クリック。ユーザ名（ここではVpnUser）をタイプし、「Add]をクリック。ユーザ権限をデータがRead/Write出来るバックアップ・アカウントに変更

「Share」ボタンをクリックし、このフォルダはVPN経由でのアクセスが可能になります。
●バックアップ・プラン・ウィザードから Files か Image Based　ボタンをしてスタート。Filesはファイル・レベルのバックアップ、Image-Basedはロー・レベルのボリューム全体のキャプチャが可能です。DRプランでどちらを選ぶかの選択になります。

●次にローカル/クラウド・バックアップかハイブリッド・バックアップにするかのバックアップ・ストラテジーの選択が必要になります。最初のオプションでは、ローカルストレージまたはクラウドサービスのいずれかに個別のデータコピーを作成できます。しかしハイブリッドバックアップでは両方の組み合わせが可能で、弾力性のあるデータ保護ソリューションが可能です。
今回の例ではローカル/クラウド・バックアップを使用します。
●Select Backup Storage ステップでストレージ・アカウントの追加が可能です。リモート共有フォルダに接続するために「 File System」を選択します。

●次のステップでは、共有フォルダのパスとユーザー認証情報を入力する必要があります

認証提供後に接続テストとアクセスする共有フォルダの検証が可能です。

●残りのバックアップ計画オプションも設定します。

リモート・リポジトリは、VPNネットワークが接続されている場合にのみ使用できることに注意してください。

タグ: , , ,

AWS EC2のディスクアレイ（LVMやダイナミックディスク）をバックアップ　パート3：EBSボリュームで構成されたLVM

投稿日: 2018年4月6日 クライム
クラウド・仮想インフラ

パート2では、EC2でディスクアレイに対してEBSスナップショットでバックアップを行う場合の課題をご紹介しました。今回は、複数のEBSボリュームにまたがり、構成されたLVMボリュームでバックアップを実行する場合についてご紹介します。


この場合、EBSスナップショットで一貫性のある状態が取得されていることを確認する必要がありますが、AWS APIは現状、完全に同一タイミングで複数ボリュームのスナップショットを取得することはできません。

しかしLVMでは、自身がLVMスナップショットを作成できます。LVMスナップショットは、元のボリュームのボリュームグループに存在し、スナップショット作成以降の元のボリュームに対する全ての変更を保存します。ただ、LVMスナップショット自体をバックアップとして使用することは推奨されません。理由は以下の通りです。

  • LVMはコピーオンライトメカニズムを使用し、変更をスナップショット領域にコピーします。これはリソースを消費し、論理ボリュームのI/Oパフォーマンスに悪影響を与える場合があります。
  • スナップショットはプライマリディスク上のストレージ容量を消費します。
  • スナップショットはプライマリデータに依存しているため、データ損失や破損、停止が発生した場合、プライマリデータと同様に役に立たないものとなります。

このように単体ではバックアップとして使用できないものですが、LVMスナップショットはEBSスナップショットと組み合わせて使用した場合、ボリュームレベルでの整合性を保証する強力な手段となります。EBSスナップショットを作成する直前に、最小限のストレージスペースを割り当ててLVMスナップショットを作成します。その後、EBSスナップショットの作成が完了した直後にLVMスナップショット削除すれば、LVMスナップショットを保持する時間は非常に短時間となり、パフォーマンスへの影響や大容量のストレージスペースの消費といった問題は回避できます。そして、この時に作成されたEBSスナップショットには削除されたLVMスナップショットが含まれます。そのため、復旧する際にLVMスナップショットを使用し、整合性を保った状態への戻すことも可能になります。

LVMスナップショットを作成する際には以下のような実行します。このコードは、スクリプト実行が可能な各種バックアップソフトで使用できますが、ここではCloud Protection Manager(CPM)を使用した場合を例としてご紹介します。CPMを使用する場合、ポリシーを作成し、そのポリシーを各インスタンスやボリュームに割り当てます。このポリシー設定で、EBSスナップショットを作成する直前と直後に実行するスクリプトを指定可能です（beforeおよびafterスクリプト）。これらのスクリプトはCPMサーバインスタンス上で実行され、SSH使用してバックアップ対象のインスタンスに接続しLVMスナップショットに関する操作を実施します。

beforeスクリプト

ここではLVMスナップショットに関するコードのみですが、この前処理としてアプリケーションの静止を実施しているものとします。

#!/bin/bash
ssh -i @ “lvcreate -n snapvolcpm -L 1G -s /dev/mapper/VolGroup00-MyVol00”
if [ $? -gt 0 ]; then
echo “Failed taking lvm snapshot” 1>&2
exit 1
else
echo “lvm snapshot succeeded” 1>&2
fi

このスクリプトではインスタンスにSSHを使用して接続し、事前定義した名前でLVMスナップショットを作成するコマンドを実行しています。実際に運用で使用する際には、さらにエラーチェックを追加する必要がある場合があります。バックアップポリシーに一つ以上のLVMボリュームグループが含まれる場合には、複数のLVMスナップショットを作成する必要があります。

afterスクリプト

ここでは単純にLVMスナップショットの削除を行っています。

#!/bin/bash
if [ $1 -eq 0 ]; then
echo “There was an issue running the first script” 1>&2
fi
ssh -i @“lvremove –force /dev/VolGroup00/snapvolcpm”
if [ $? -gt 0 ]; then
echo “Failed removing lvm snapshot” 1>&2
exit 1
else
echo “remove lvm snapshot succeeded” 1>&2
fi

これらのスクリプトを構成後、LVMにはEBSスナップショットの作成時以外、LVMスナップショットは存在しませんが、EBSスナップショットからリカバリを行うと、その中にはLVMスナップショットが含まれます。インスタンスを復旧するために全てのEBSボリュームをリストア後、最初に、LVMスナップショットに戻す操作が必要になります。そのため、復旧後のインスタンスにログイン後、以下のようにコマンドを実行します

umount / dev / mapper / VolGroup00-MyVol00
lvconvert -merge / dev / VolGroup00 / snapvolcpm
mount/ dev / mapper / VolGroup00-MyVol00 / volume_mountpoint

これらのコマンドで、ボリュームは一度アンマウントされ、スナップショットをメインボリュームとマージした後、再度マウントします。これにより、ボリュームマネージャレベルで一貫性を保証した上で、EBSスナップショットを活用した、効率的で高速なバックアップを実現できます。


タグ: , , ,

AWS EC2のディスクアレイ（LVMやダイナミックディスク）をバックアップ　パート2：一貫性問題

投稿日: 2018年4月5日 クライム
AWS クラウド・仮想インフラ

パート1では、EC2でディスクアレイ構成を行うこと自体の意味に関してご紹介しました。

どのようにディスクアレイの一貫性を保証するか？ストレージスタックについて考える場合、それぞれの階層が他の階層の実装を認識していないことを意識する必要があります。例えばストレージの層でパフォーマンスの向上のためにキャッシュが実装されているとします。この場合、アプリケーションが開いているファイルのデータは実際にはメモリ内キャッシュに存在するかもしれません。しかし、アプリケーションはファイルシステムがキャッシュを実装しているか、またどのようにデータをキャッシュしているかは必ずしもわかりません。つまり、アプリケーションがデータを保存するためにはファイルを閉じるか、ファイルシステムにデータをフラッシュするための特殊なAPIを用いる必要があります。ただ、ファイルシステムとボリュームについては同じようにはいきません。

ディスク（EBSボリューム）のスナップショットショットをとることは可能ですが、キャッシュされたデータがスナップショット実施前フラッシュされていない場合、その結果は矛盾したイメージになります。ほとんどの場合、アプリケーションは停電後のシステムクラッシュから回復するのと同様に、不整合から復旧することができますが、これには手間がかかります。また、ディスクアレイの場合、キャッシュがフラッシュされたとしても、全てのディスクが100%同期しているわけではない可能性があるため、より注意する必要があります。

ディスクアレイのバックアップで一貫性を保証する場合、まず、アプリケーションが一貫性のある状態になっていることを確認します。これは通常、アプリケーション（OracleやMySQL、MongoDBなど）が提供する様々なAPIを用いて実行できます。次、ボリュームについてですが、単一のディスク（EBSボリューム）で構成されている場合にはアプリケーションレベルの静止のみで十分です。複数のEBSボリュームを持つディスアレイの場合には、全てのスナップショットで、全てのボリュームが同期されていることを確認するため、ボリュームマネージャが一貫性のある状態になっていることを確認する必要があります。順番としては以下のように実施します。

  1. アプリケーションの一貫性を確認
  2. ボリュームマネージャの一貫性を確認
  3. EBSスナップショットを作成

ボリュームマネージャの一貫性（環境ごとの違い）

Windowsダイナミックディスク

Windowsは十分に統合された環境であり、ディスクアレイは通常、ダイナミックディスクと呼ばれるWindowsの内部メカニズムを使用して定義されます。Windowsのダイナミックディスクでは複数のディスクにまたがるボリュームやソフトウェアRAIDを定義できます。Windowsの場合、ストレージスタック全体のバックアップはVSS（ボリュームシャドウコピー）と呼ばれるインフラストラクチャによってカバーされています。これによりSQL ServerやExchange、SharePointといったMicrosoftアプリケーションはVSS経由で一貫性のあるバックアップをサポートしています。

VSSサポートするバックアップソリューション（N2WS CPMやVeeam Backup and Replication、CloudBerry Backupなど）では、このVSS経由の処理でアプリケーションレベル、ファイルシステムレベル、ダイナミックディスクとして構成されたボリュームなどで一貫性のある状態を保証できます。

Linux Mdadm

LinuxでmdadmはソフトウェアRAIDの作成と管理のために使用されるユーティリティです。これ自体がボリュームマネージャではありません。スナップショットやバックアップはサポートされておらず、多くの場合mdadmはスナップショットをサポートするLVM（論理ボリュームマネージャ）と組み合わせ使用されます。

mdadmを単独で使用する場合には、アプリケーションレベルとファイルシステムレベルでの一貫性まで保証できます。例えばLinuxのxfsファイルシステムでは、ファイルシステムをフラッシュし、静止した状態にすることができます。これにより、mdadmのソフトウェアRAIDでスナップショットを作成する際のリスクを軽減できます。

LVMを使用している場合には、mdadmと組み合わせるかどうかにかかわらず、EBSスナップショットをしたEC2のバックアップに使用できる内部LVMスナップショットがあります。次のパート（作成中）ではこのLVMバックアップについてご紹介します。

タグ: , , ,