仮想化・クラウドをよりよく活用する4つのヒント【AXIES2021】
•Download as PPTX, PDF•
0 likes•522 views
仮想化・クラウドは、容易に構築が可能で、リソースの無駄をなくせる、障害に強くなる、コスト削減になるなど様々なメリットがあります。 このセミナーでは、ただこれらの環境を使用するだけでなく、よりよく活用するために考えることについて紹介します。 1.確実な保護に必要な3-2-1ルール 2.移行に大事なこと 3.VMware認定暗号化キー管理サーバー 4.Kubernetesのアプリケーション保護手法 ※AXIES2021で行ったセッションの資料です。
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Similar to 仮想化・クラウドをよりよく活用する4つのヒント【AXIES2021】
Similar to 仮想化・クラウドをよりよく活用する4つのヒント【AXIES2021】 (20)
More from 株式会社クライム
More from 株式会社クライム (20)
仮想化・クラウドをよりよく活用する4つのヒント【AXIES2021】
- 2. クライム • 設立：1984年 • 所在地：東京都中央区日本橋 大阪・名古屋・福岡事業所 • 主な事業内容： ソフトウェアの販売とサポート 物理・仮想・クラウド・データベース等の データ保護、データ連携 © 2021 Climb Inc. 2
- 3. アジェンダ 1. 確実な保護に必要な3-2-1ルール 2. 移行に大事なこと 3. VMware認定暗号化キー管理サーバー 4. Kubernetesのアプリケーション保護手法 © 2021 Climb Inc. 3
- 4. アジェンダ 1. 確実な保護に必要な3-2-1ルール 2. 移行に大事なこと 3. VMware認定暗号化キー管理サーバー 4. Kubernetesのアプリケーション保護手法 © 2021 Climb Inc. 4
- 5. バックアップとは • システムの異常や機器の故障などのトラブルによる データの破損に備えて、データを複製すること。 • バックアップ対象となるデータは、画像データや書類データなど、 利用するすべてのデータが該当する。 • 予期しない障害によるデータ破損を回避する方法がバックアップ。 © 2021 Climb Inc. 5
- 6. 予期しない障害の例 • 自然災害：地震、火災、台風、洪水 • ハードウェア障害：経年劣化、ハードの故障 • オペレーションミス：ファイルの削除 • コンピュータ・ウイルス：不正アクセス、データ改ざん © 2021 Climb Inc. 6
- 8. 障害による影響 0 8 16 24 年間売上 100億円の場合 データ欠損時間 = 24時間 復旧に要する時間 = 24時間 過去24時間のデータ損失 + 復旧に24時間 = 48時間の損失 = 損失額：約5400万円 0 8 16 24 過去4時間のデータ損失 + 復旧に4時間 = 8時間の損失 = 損失額：約900万円 復旧に要する時間 = 4時間 データ欠損時間 = 4時間 © 2021 Climb Inc. 8
- 9. データ保護で考えること • RPO (目標復旧時点) データをいつの時点に戻せるかを示す 短いほど最近の状態に戻せる • RTO (目標復旧時間) データを復旧するまでの時間を示す 短いほど復旧が速い 障害発生 秒 分 時 日 週 週 日 時 分 秒 RPO RTO © 2021 Climb Inc. 9
- 10. データ保護の方法 • バックアップ： データを圧縮してストレージやテープに保管 RPO：1日 RTO：数時間～数日 • レプリケーション： データの複製を別環境に作成 RPO：数分 RTO：数分～数時間 © 2021 Climb Inc. 10
- 11. データ保護の方法 • バックアップ： RPO：1日 RTO：数時間～数日 メリット：様々な媒体に保存可能 デメリット：データにアクセスするためにリストアが必要 • レプリケーション： RPO：数分 RTO：数分～数時間 メリット：障害時に即座に復旧が可能 デメリット：運用側と同じだけのリソースが必要 © 2021 Climb Inc. 11
- 12. 3-2-1ルール • データのバックアップを取るための理想的な方法の一つ • データをコピーして3つ持つ（運用データとバックアップデータを2つ） • 異なる2種類のメディア（ディスクとテープ等）でバックアップを保存 • バックアップの内1つは（物理的に異なる）別の場所で保管 © 2021 Climb Inc. 12
- 13. 3-2-1ルール © 2021 Climb Inc. 13 レプリケーション バックアップ コピー
- 14. ③ ① ② 3-2-1ルール（3つのコピー） © 2021 Climb Inc. 14 レプリケーション バックアップ コピー
- 15. ② ① 3-2-1ルール（2種類のメディア） © 2021 Climb Inc. 15 レプリケーション バックアップ コピー
- 16. ① 3-2-1ルール（1つはオフサイト） © 2021 Climb Inc. 16 レプリケーション バックアップ コピー
- 17. 3-2-1-1-0ルール • ランサムウェアの脅威に対して2つの追加ルール • データをコピーして3つ持つ（運用データとバックアップデータを2つ） • 異なる2種類のメディア（ディスクとテープ等）でバックアップを保存 • バックアップの内1つは（物理的に異なる）別の場所で保管 • 不変性/オフラインバックアップを1つ • バックアップからのリストア検証でエラーを0に © 2021 Climb Inc. 17
- 18. ① 3-2-1-1-0ルール（1つの不変コピー） © 2021 Climb Inc. 18 レプリケーション バックアップ コピー イミュータブル（変更不可）な ストレージ ランサムウェアによる 暗号化を防ぐ
- 19. 3-2-1-1-0ルール（リストアエラー0） © 2021 Climb Inc. 19 レプリケーション バックアップ コピー 運用に影響を与えない隔離環境に VMをリストア エラーなくリストアできるかを 定期的に検証
- 20. 3-2-1-1-0ルールを実現するには • ランサムウェアの脅威に対して2つの追加ルール • データをコピーして3つ持つ（運用データとバックアップデータを2つ） • 異なる2種類のメディア（ディスクとテープ等）でバックアップを保存 • バックアップの内1つは（物理的に異なる）別の場所で保管 • 不変性/オフラインバックアップを1つ • バックアップからのリストア検証でエラーを0に © 2021 Climb Inc. 20
- 21. 3-2-1-1-0ルールを実現するには • ランサムウェアの脅威に対して2つの追加ルール • データをコピーして3つ持つ（運用データとバックアップデータを2つ） • 異なる2種類のメディア（ディスクとテープ等）でバックアップを保存 • バックアップの内1つは（物理的に異なる）別の場所で保管 • 不変性/オフラインバックアップを1つ • バックアップからのリストア検証でエラーを0に © 2021 Climb Inc. 21
- 22. Veeam • バックアップとレプリケーションの2in1 • マシンの用途に合わせて使い分けが可能 • 緊急性の低いものはバックアップ • 緊急性の高いものはレプリケーション © 2021 Climb Inc. 22
- 23. あらゆる環境に対応 • 物理、仮想、クラウドのデータ保護を統合 • テープ、クラウド、重複排除ストレージなど柔軟な保存先 © 2021 Climb Inc. 23
- 24. 手軽に導入するなら “Druva” • AWS上に構築され、 「as-a-Service」として提供 • いつでも、どこでもクラウドへデータを保護 • 簡単で高速なデータ検索 • 情報漏洩対策（DLP） © 2021 Climb Inc. 24
- 25. セキュリティ対策 • 正確な位置情報追跡 • 紛失や盗難されたデバイスから重要データを遠隔地から削除 • デバイス上でのファイル強制暗号化 • 急な暗号化ファイルの増加や削除を 見つけてアラート © 2021 Climb Inc. 25
- 26. クラウドインスタンスのバックアップ © 2021 Climb Inc. 26
- 27. AWSの機能でも充分？ • EBSスナップショットでバックアップ 小規模なら手動でも、大規模な環境では難しい・・・ • インスタンスごとのスケジュール、世代管理、静止点・・・ • リストアの単位（全体、ディスク、ファイル） 柔軟なリストア要件に対応するには手順が複雑に・・・ © 2021 Climb Inc. 27
- 28. N2WS Backup & Recovery © 2021 Climb Inc. 28
- 29. アジェンダ 1. 確実な保護に必要な3-2-1ルール 2. 移行に大事なこと 3. VMware認定暗号化キー管理サーバー 4. Kubernetesのアプリケーション保護手法 © 2021 Climb Inc. 29
- 30. 移行に大事なダウンタイム © 2021 Climb Inc. 30 VM構築 Import Export 切り替え 運用開始 VM構築 レプリケー ション 切り替え 運用開始 通常の移行 レプリケーションによる移行 システム停止期間 全件＋差分
- 31. リアルタイムレプリケーション © 2021 Climb Inc. 31 メイン vCenter VM VM DR vCenter VR ZVM ZVM VRA VRA VRA VRA VPG VM VM ZVM VRA 管理サー バ (Windows) データ処理 VPG VM単位の設定 ディスク全体を初期同期
- 32. リアルタイムレプリケーション © 2021 Climb Inc. 32 メイン vCenter VM VM DR vCenter VR ZVM ZVM VRA VRA VRA VRA VPG VM VM ZVM VRA 管理サー バ (Windows) データ処理 VPG VM単位の設定 VMから仮想ディスクへの書き込みをキャプチャ
- 33. リアルタイムレプリケーション © 2021 Climb Inc. 33 メイン vCenter VM VM DR vCenter VR ZVM ZVM VRA VRA VRA VRA VPG VM VM ZVM VRA 管理サー バ (Windows) データ処理 VPG VM単位の設定 キャプチャしたデータをレプリケーション
- 34. リアルタイムレプリケーション © 2021 Climb Inc. 34 メイン vCenter VM VM DR vCenter VR ZVM ZVM VRA VRA VRA VRA VPG VM VM ZVM VRA 管理サー バ (Windows) データ処理 VPG VM単位の設定 移行先のディスクに書き込み
- 35. 移行先は自由自在 © 2021 Climb Inc. 35 Azure
- 36. データベースの移行なら • マシン、ファイルレベルではデータベースの要件は満たせない • できる限りリアルタイムな移行 • トランザクションレベルでの移行 • 災対側DBのコスト減 © 2021 Climb Inc. 36
- 37. Syniti Data Replication • 異種DB間：Oracle/MSSQL/MySQL/DB2/PostgreSQLなど • トランザクション単位：INSERT/UPDATE/DELETE • データ保護・連携にも利用可能 © 2021 Climb Inc. 37
- 38. サポートするデータベース © 2021 Climb Inc. 38 IBM DB2 for i(AS/400) IBM DB2 for z/OS IBM DB2 for AIX, Linux, Windows Oracle MS SQL Server MS Azure SQL Database MySQL/Amazon Aurora/MariaDB Gupta SQLBase IBM Informix SAP Sybase ASE SAP Sybase SQL Anywhere IBM PureData(Netezza) PostgreSQL Amazon Redshift SAP HANA SAP Sybase IQ Actian Vectorwise HP Vertica MS Access Firebird Ingres IBM SolidDB IBM dashDB Teradata Hadoop
- 39. アジェンダ 1. 確実な保護に必要な3-2-1ルール 2. 移行に大事なこと 3. VMware認定暗号化キー管理サーバー 4. Kubernetesのアプリケーション保護手法 © 2021 Climb Inc. 39
- 40. VMware認定暗号化キー管理サーバー © 2021 Climb Inc. 40 VM暗号化 VMware vSAN™暗号化 vTPM
- 41. vSphere暗号化、vSAN暗号化の事前準備 © 2021 Climb Inc. 41 HyTrust: HyTrust KeyControlを 仮想環境へデプロイ 証明書の発行 01. VMware: 暗号化を行いたい VMware vCenter®に KeyControlを登録 02. VMware: vSphere Web Client からvSphere暗号化、vSAN 暗号化をチェック 03. STEP 1 STEP 2 STEP 3
- 42. VMからクラウドまで暗号化 © 2021 Climb Inc. 42 Azure
- 43. アジェンダ 1. 確実な保護に必要な3-2-1ルール 2. 移行に大事なこと 3. VMware認定暗号化キー管理サーバー 4. Kubernetesのアプリケーション保護手法 © 2021 Climb Inc. 43
- 44. Kubernetesでバックアップは必要か？ © 2021 Climb Inc. 44 Worker 0 Worker 1 Master 0 Master 1 Master 2 Worker 2 Pod-aaaa Pod-bbbb Pod-cccc Pod-dddd Pod-eeee Pod-ffff
- 45. Kubernetesでバックアップは必要か？ © 2021 Climb Inc. 45 Worker 1 Master 0 Master 1 Master 2 Worker 2 Pod-aaaa Pod-bbbb Pod-cccc Pod-dddd Pod-eeee Pod-ffff Worker 0 Pod-gggg Pod-hhhh
- 46. Kubernetesでバックアップは必要か？ © 2021 Climb Inc. 46 Worker 1 Master 0 Master 1 Master 2 Worker 2 Pod-aaaa Pod-bbbb Pod-cccc Pod-dddd Pod-eeee Pod-ffff Worker 0 Pod-gggg Pod-hhhh クラスタ全体の障害には対処できない
- 47. コンテナイメージのバックアップでは？ © 2021 Climb Inc. 47 個数 コンポーネントの種類 106 Pods 92 Secrets 87 Services 76 Deployments 70 Certificates 36 ConfigMaps 16 Persistent Volumes 55 Other Components 538 合計 一貫性、依存関係の再構成が問題、 ステートフルは対応できない
- 48. アプリケーション中心のアプローチ © 2021 Climb Inc. 48 運用単位としてのアプリケーション 完全なアプリケーション キャプチャを実現 一貫性のあるデータとアプリケーションリソース オペレーションを調整し実行 リソースとデータオペレーションを適切な順序で 基盤インフラストラクチャの抽象化 ストレージとデータサービスをシームレスに
- 49. K8sのバックアップとモビリティを簡単に © 2021 Climb Inc. 49 エンタープライズ プラットフォーム オペレータも簡単操作 使いやすく、 簡単なUX ポリシーでの 自動化 エンドtoエンド セキュリティ App検出
- 50. まとめ © 2021 Climb Inc. 50 ・サービスで提供 ・テレワークのセキュリティ ・バックアップとレプリケーション ・あらゆる環境に対応 ・リアルタイムレプリケーション ・オンプレからクラウドへ ・アプリケーション上の データはユーザー責任 ・複雑なデータ保護をGUIで簡単に ・アプリケーション単位のデータ保護 ・別環境のK8sへの移動も簡単に ・トランザクション単位の レプリケーション ・アプリケーションとのデータ連携、 移行にも
- 51. クライムへのお問合せ • ホームページ：https://www.climb.co.jp/ • 電話番号：東京 03-3660-9336 大阪 06-6147-8201 • お問合せフォーム： https://www.climb.co.jp/soft/contact/contact.php © 2021 Climb Inc. 51 データ保護・データ連携・DRをご検討の際には、 お問合せください！
Editor's Notes
- みなさん、こんにちは。株式会社クライムです。 本日は「仮想化・クラウドをよりよく活用する4つのヒント」についてお話させていただきます。
- まずは、簡単に弊社クライムについてご紹介させていただきます。 設立1984年、東京都中央区日本橋を拠点とし、大阪、名古屋、福岡に事業所を置いております。 海外製のソフトウェアの販売とサポートを主な事業内容としており、物理・仮想・クラウド・データベース等のデータ保護、データ連携のソフトウェアを主に扱っている企業です。
- では早速本日のアジェンダです。 1.確実な保護に必要な3-2-1ルール 2.移行に大事なこと 3.VMware認定暗号化キー管理サーバー 4.Kubernetesのアプリケーション保護手法 の4つです。
- まずは、1つ目「確実な保護に必要な3-2-1ルール」について
- いくつか災害の例を挙げてみました。 地震、火災、台風のような自然災害もありますし、経年劣化などによるハードウェア障害も考えられます。 または重要なファイルを間違って削除してしまったり、外部からの不正アクセスによるデータ改ざんなど、人的な災害も考えられます。 このような災害に見舞われると具体的にどのような影響が出るのか、以前に実際にあった例をいくつか紹介します。
- 全て医療関連での事例となりますが、 1つ目の事例として、「電子カルテが使用できなくなってしまい、外来診療を休診することに。また、救急車による救急搬送の受け入れも一時休止」となりました。 2つ目は「ランサムウェアによって医療システムが使用できなくなり、復旧するまでの間、患者を別の病院へ転院することに」、 そして、3つ目の事例では「医療サービスの一部が機能不全に陥り、手術やその他の医療処置のスケジュールを変更」することになるなど、 病院の信頼性にも影響が出かねない問題が発生してしまいます。 また、金銭面の影響も大きいものがあります。
- この図は年間売上が100億円の企業で災害が発生した場合の損失額について計算したものです。 もし、災害が発生し、過去24時間分のデータが失われ、さらにシステムの復旧に24時間かかってしまった場合、合計48時間分の損失が発生することになります。 年間売上100億円の場合、単純計算で48時間分の損失額は5400万円となります。 一方、失われたデータが過去4時間分で、復旧にかかった時間も4時間で済めば、8時間分の損失となり、損失額を900万円まで抑えることができます。 このように可能な限り、データの損失を少なく、復旧にかかる時間を短くすることによって、災害による影響を抑えることができます。 この「データ損失を少なく」、「復旧時間を短く」というのが、災害対策を考えるうえで大事なこととなってきます。
- これらはそれぞれ「RPO」「RTO」というキーワードで表されています。 「RPO」は「目標復旧時点」となりデータをいつの時点に戻せるかを示します。短ければ短いほど最近の状態に戻せるということです。 「RTO」は「目標復旧時間」となりデータを復旧するまでの時間を示しています。短いほど早く復旧できます。 これらの値を短くすることで災害の影響を小さくすることができるため、災害対策BCPを考えるうえで重要になってきます。 実際に災害対策をする手法としては、様々な方法がありますが、今回は2つの手法について紹介します。
- 「バックアップ」と「レプリケーション」の2つです。 「バックアップ」はデータを圧縮してストレージやテープに保管する方法です。一般的にRPOは「1日」、つまり1日前の状態に戻せ、RTOはデータ量によって変わってくるため幅がありますが、「数時間～数日」で復旧が可能です。。 一方「レプリケーション」はデータの全く同じ複製を別環境に作成する方法です。RPOは「数分」、RTOは「数分～数時間」となります。 ここだけ聞くとレプリケーションの方が、RPO、RTOが短くできるため、良いように思えますが、それぞれにメリット、デメリットがあるため、一概にどちらかがいいとは言えません。 まずは、バックアップについてもう少し詳しく説明します。
- VMwareによってデータセンターなどを仮想化することによって、すべてを物理で構成することに比べ、障害にも強くなっています。 しかし、それはバックアップを取らなくてもいいということにはなりません。 バックアップの理想的な方法の一つとして、「3-2-1ルール」があります。 データをコピーして3つ持つ 異なる2種類のメディアでバックアップを保存 バックアップの内1つは別の場所で保管 このルールを満たすことで確実なデータ保護ができるというものです。
- 構成例で具体的に説明します。
- まず、「3つのコピー」、 ①運用データと②③のバックアップデータをあわせて3つ保持する。 これによって、どれか一つが壊れても復旧して、運用をけいぞくすることができます。
- 次に「2種類のメディア」、 例えば、①ディスクと②テープやクラウドです。 同時期に用意した同じメディアでは破損も同じタイミングで発生する可能性があります。 こうなりますとディスクの破損によって復旧することができません。 異なるメディアに保存することですべてのバックアップが同時に破損することを防げます。
- 最後が「1つはオフサイト」へ。 地震や火災など拠点ごと利用不可な状況に陥る可能性もあります。 そんなときバックアップの1つを遠隔地に保存しておけば、 例え拠点ごとバックアップを含むすべてのデータが消えたとしても、 無事な遠隔地のバックアップデータから復旧が可能です。 これらの理由から「3-2-1ルール」は理想的なバックアップの方法とされています。
- しかし、近年のランサムウェアの脅威によって、 「3-2-1ルール」ではデータ保護として不十分ではないかという考えから、 「3-2-1-1-0ルール」というさらに2つのルールを追加したデータ保護の方法も考えられています。 従来の「3-2-1ルール」に、 不変性/オフラインバックアップを1つ バックアップからのリストア検証でエラーを0に という2つのルールを追加しています。
- まず、「1つの不変コピー」というのは、 いわゆるimmutable、変更不可な状態でバックアップを保存するというものです。 例えば、AWSやAzureなどのクラウドで利用可能な機能ですが、 バックアップファイルを上書き禁止にすることで、 ランサムウェアによってバックアップファイルが暗号化されたり、 利用できない状態にされることを防ぐことが可能になります。
- そして、「リストアエラー0」についてです。 いくらバックアップを取っていても、いざ必要な時に復旧できなければ意味がありません。 そんなバックアップファイルの健全性を確認するために、 例えば、運用に影響を与えない隔離環境を作り、実際にリストアしてみて、 復旧に使えるバックアップなのかを確認することが重要になります。
- これらのルールはデータを保護するための理想の方法とはなりますが、 すべてを満たしたデータ保護環境を構築するには手間もコストもかかります。 そのため、何らかのソリューションを考える必要が出てくるでしょう。
- そこでクライムがご提案するのがVeeamです。 Veeamは「3-2-1-1-0ルール」をこれ単体で実現することができます。 「3-2-1-1-0ルール」を満たした確実なデータ保護ならVeeamにお任せください。
- まずは、Veeam、「バックアップとレプリケーションの2in1」とあるようにこれ一つでバックアップとレプリケーションの両方が行えます。 そのため、緊急性の高いものはレプリケーション、低いものはバックアップとマシンの用途に合わせて災害対策の方法を使い分けることができます。 また、一般的にはバックアップからの復旧は数時間かかってしまうことが多いのですが、Veeamの独自技術によりバックアップからも数分で復旧し起動することができる機能を持っています。
- バックアップ保存先としてS3が付属 物理的なハードを用意する必要がない クラウドへのバックアップなのでバックアップ対象がインターネットに接続できれば、いつでも、どこでもバックアップが可能
- クラウドインスタンスを使用する場合、例えば、AWSの場合、EC2、EBS、RDSなどのリソースをAWSコンソール上で用意して、その上にアプリケーションをインストールしたり、データを置いたりします。 EC2、EBS、RDSなどのハードウェア部分のセキュリティや保護の責任はAWS側で負いますが、EC2、EBS、RDSなどのリソースの上に載っているアプリケーション上のデータについてはお客様側で責任をもって保護する必要がある。 そのため、クラウドだからと安心せずにデータ保護の方法を考える必要がある。
- 2つ目「仮想マシンの移行に大事なこと」
- 移行を考えるうえで重要なのはダウンタイムをいかに短くするかです。 VMのエクスポート、インポートによる移行では、エクスポート前から切り替えが完了までシステムが停止し、 VMのサイズが大きければ大きいほどダウンタイムが発生してしまいます。 それに対し、レプリケーションであれば、すでに移行先にVMが存在し、切り替え直前までデータを同期することで、 システム停止期間を切り替えのタイミングのみに短くすることができます。 そのため、レプリケーションはリアルタイムであればあるほどいいでしょう。
- ただ、VMのバックアップやレプリケーションでは大抵の場合、VMスナップショットがとられます。 1回1回はそこまで負荷がかかるものでもないですが、数分単位、数秒単位で作成、削除が行われるのはいいものではありません。 その点、Zertoはスナップショットを使わないレプリケーションが可能です。 例えば、この図はオンプレのVMwareからGoogle Cloud VMware Engineへ移行する場合を想定しています。 最初にディスク全体の初期同期を実施後、
- VMからディスクへの書き込み、変更点をキャプチャし、
- キャプチャしたデータをGoogle Cloud側へ転送します。
- そして、オンプレ側でディスクに書き込むのと同様にGoogle Cloud側のディスクへも書き込むことで、同期をとることができます。 移行元VMへの書き込みをリアルタイムで移行先にも書き込むので あとは移行先のVMを起動するだけで移行が完了します。 このようにZertoを使えばダウンタイムを最小限に抑えた移行が可能です。 もちろん単純に災害対策としても使用できます。
- Zertoは他にもAWS、Azure、Oracle Cloudにも対応しており、移行先は自由自在です。
- データベースには重要なデータが多く保存されているため、できる限りリアルタイムなデータ保護を求める声も多いと思います。 データベースに備え付けられているレプリケーション機能もありますが、この場合、大抵同じデータベース間で利用可能なので、有償データベースを使っている場合、災対側にも有償でデータベースを用意する必要があります。 単純にデータベース2台分の費用に、もしかしたらレプリケーション機能を利用するためのオプション費用が掛かるかもしれません。
- 3つ目「VMware認定暗号化キー管理サーバー」
- vCenterの暗号化機能を使用するには、KMS、キー管理サーバーが必要です。 HyTrustはVMware認定のキー管理サーバーとなっており、 VM暗号化、vSAN暗号化、vTPMに使用できます。
- HyTrustはアプライアンスとして提供されており、 vCenterに登録後、vSphere Web Clientで暗号化を有効にするだけで簡単に暗号化できます。
- さらにVMだけでなく、HyTrust独自の方法でクラウドインスタンスの暗号化も可能ですので、 暗号化のご要望があればHyTrustにお任せください。
- 4つ目「VMware Tanzu、Kubernetesのアプリケーション保護手法」
- VMware Tanzuによって、Kubernetesが統合され、コンテナも利用できるようになりました。 ここで考える必要があるのが、Kubernetesにバックアップが必要かどうかということです。 複数のWorker、クラスタで構成していれば、
- どれか一つのWorkerが壊れたとしても、別のWorkerでPod、アプリケーションを再実行すれば問題ないですが、
- クラスタ全体で障害が発生してしまったらどうしようもありません。 このことからやはりKubernetesもバックアップが必要といえるでしょう。
- ただ、VMのバックアップと同じようにコンテナイメージのバックアップでは、 リストア時の一貫性や依存関係の再構成が問題になります。
- そのため、Kubernetesのバックアップを行うにはアプリケーション中心のアプローチをとる必要があります。 アプリケーション単位でデータ保護を考えることで、一貫性のあるバックアップが行え、 基盤インフラストラクチャの抽象化、つまり、VMware Tanzuに限らず、Amazon EKSやAzure Kubernetes Serviceなど、 様々なプラットフォームのKubernetesのバックアップが可能です。
- Kasten K10は自動でアプリケーションを検出し、ポリシーベースでバックアップを自動化できます。 VMware Tanzuに限らず、Kubernetesのデータ保護にオススメのソリューションとなっています。
- 質疑応答