クロスクラウド・ディザスターリカバリー(DR)： クラウドコンピューティングの新時代

投稿日: 2024年2月12日 クライム
AWS Azure クラウド・仮想インフラ

クラウドの拡張性、適応性、費用対効果を活用するために、多くの組織がアプリケーションをクラウドに移行していることは紛れもない事実です。そのため、デジタル資産の中断のない可用性と保護を確保するために、堅牢なクロスクラウド・ディザスタリカバリ（DR）システムを確立することが極めて重要です。

クラウドは拡張性が高いかもしれませんが、リスクがないわけではありません。サイバー脅威、自然災害、人為的なエラーにより、DRシステムは企業にとって戦略的に必要不可欠なものとなっています。従来のDRアプローチでは、デジタル資産の量と複雑さの両方が増大するにつれて、不十分であることが判明することがよくあります。クロスクラウド・ソリューションを採用することで、このような欠点に対処し、包括的なデータ保護戦略を確保することができます。

ここは、クラウド内でのDRの最適な方法、単一のクラウドプロバイダー内でのDRのクロスリージョン提供の非効率性、クロスクラウドDRの利点、クロスクラウドDRを採用する際の課題、そしてN2WSがどのようにクロスクラウドDR戦略の管理に役立つのかについて紹介します。

クラウド内でのディザスタリカバリの伝統的な方法

最新のDR戦略は、Amazon Web Services (AWS)やMicrosoft Azureのような主要なクラウドサービスプロバイダーによって利用されてきた伝統的な手法によって確立された強固な基盤に基づいている。これらの伝統的な手法をさらに深く考えてみます。

AWSにおけるディザスタリカバリ

AWSにおけるディザスタリカバリのアプローチは、主にアプリケーションを迅速かつ効率的にリカバリする能力を中心に展開されています。AWSの顧客がアプリケーションとデータをリカバリする必要がある状況に遭遇した場合、AWSはわずか数分でリカバリインスタンスを起動する機能を提供します。

これにより、ダウンタイムとサービスの中断を最小限に抑えることができます。さらに、これらのインスタンスは、最新のサーバー状態に基づくことも、状況に応じてユーザーが選択した過去の時点から起動することもできます。

ストレージ層に基づくRTOとRPO
リカバリ時間目標（RTO）とリカバリポイント目標（RPO）（リカバリプロセス中の許容可能な時間とデー タ損失を定義する重要な尺度）は、データのスナップショットが存在する場所によって異なります。たとえば、次のようなストレージ階層に基づいてRTOとRPOを計算できます：

●標準EBSブロック・ストレージ： 標準EBSブロック・ストレージ：優れた効率性と低レイテンシを必要とするワークロード向けに設計されています。このストレージ層はRTOとRPOの時間が速く、ミッションクリティカルなアプリケーションに適しています。

●Amazon S3：高い拡張性、耐久性、安全性を備えたオブジェクト・ストレージで、パフォーマンスとコストのバランスを提供します。RTOとRPOの指標は、EBSブロック・ストレージと比較して若干異なる場合があります。

●Glacier： 長期的なデータ・アーカイブを想定したアーカイブ・ストレージ・ソリューションで、検索時間は数分から数時間です。そのため、Glacier内のデータのRTOとRPOは通常より高くなります。

クロスリージョンDR
AWSは、真のディザスタリカバリには地理的な冗長性が重要であると認識しています。そのため、企業向けにクロスリージョンのディザスタリカバリを提供しています。これは、プライマリーリージョンが災害やサービス中断に直面した場合、全く別のリージョンにフェイルオーバーできることを意味します。これにより、データの継続的な可用性とアプリケーションのアップタイムが保証さています。

Azureにおけるディザスタリカバリ

クラウド分野のもう一つの巨人であるMicrosoft Azureも、独自の用語やニュアンスを持つものの、同様のディザスタリカバリの仕組みを提供している。

Azure Site Recovery

Azure Site Recovery（ASR）は、Azureにおけるディザスタリカバリの主力ソリューションです。仮想マシン（VM）のワークロードをある主要な場所から別の場所にレプリケートする上で重要な役割を果たす。つまり、プライマリサイトがダウンしても、アプリケーションとデータへのアクセスは維持されます。

フェイルオーバー・メカニズム

ASRを使用すると、セカンダリ・ロケーションにフェイルオーバーでき、レプリケートされたデータはライブになり、アプリケーションはアクセス可能なままになります。これにより、ユーザやビジネスプロセスへの影響を最小限に抑えることができます。

AWSとAzureはどちらも、堅牢で効率的なディザスタリカバリ戦略を備えたクラウドエコシステムに位置づけられている。用語やプロセスは若干異なるかもしれないが、中核となる目的は変わらない。クラウド・コンピューティングの新時代を迎えるにあたり、クロス・クラウドのディザスタリカバリ・ソリューションは、これらの戦略をさらに再定義することになるでしょう。

1つのクラウドプロバイダー内でのクロスリージョンDRが非効率的な理由

多くの企業が1つのクラウド・プロバイダー内でのクロスリージョンDRに頼っているが、この方法には限界がある。このセクションでは、単一のクラウド・プロバイダー内でのクロスリージョンDRだけに頼ることが、なぜ最も効率的なアプローチでないのかを探っていく。

セカンダリー・リージョンに潜在する容量の問題

企業がディザスタリカバリ計画を策定する際、通常オペレーションを行うプライマリーリージョンと、プライマリーリージョンに障害が発生した場合に使用するセカンダリーリージョンを選択することが多いのは事実です。しかし、この戦略には根本的な欠陥があります。

コンピュートとストレージの不足
単一サイトで地域障害が発生した場合、セカンダリ（バックアップ）地域の需要が急増する可能性があります。多くの企業が同時にDR計画を開始し、このセカンダリーリージョンにワークロードを移動させると、そのリージョンが圧倒される可能性があります。セカンダリーリージョンには急激な需要増に対応するキャパシティがなく、コンピュートとストレージのリソースが不足する可能性があります。その結果、パフォーマンスの低下、データ検索時間の遅延、あるいは停止につながる可能性があります。

クラウド・リージョンの相互依存
クラウドのリージョンは地理的に分散しているとはいえ、必ずしも想定されるほど独立しているわけではありません。

●レプリケーションはヒューマンエラーを排除しない： 例えば、EBS（Elastic Block Store）のスナップショットやRDS（Relational Database Service）のデータベースのようなAWSのサービスです。これらは冗長性を強化し、セキュリティを強化するために別のリージョンに複製することができます。しかし、このレプリケーションはヒューマンエラーと無縁ではありません。誰かがデータを入力する際にミスをすると、そのミスが複製されます。これにより、リード・レプリカは不正確になり、DR戦略を導入する目的そのものが損なわれてしまいます。

●偶発的な削除に対する脆弱性： もう一つの緊急の懸念は、誤って削除してしまう可能性であります。オペレーターがうっかりアプリケーション全体を削除してしまうというシナリオを想像してみてください。企業が単一のクラウド・プロバイダーしか採用せず、プロバイダー内のレプリケーションに依存している場合、その削除はリージョン間でミラーリングされてしまいます。外部バックアップやマルチクラウドDR戦略がなければ、アプリケーションは永久に失われる可能性があります。

単一クラウド・プロバイダー内でのクロスリージョンDRは冗長性のレベルを提供するが、それは特効薬ではありません。企業は、制約と潜在的な落とし穴を認識しておく必要があります。複数のクラウド・プロバイダーを活用したり、オンプレミスとクラウドのソリューションを組み合わせたりして、ディザスタリカバリ戦略を多様化すれば、より包括的でフェイルセーフなアプローチが可能になります。

クロス・クラウド・リカバリーのメリット

複数のクラウドプロバイダーの強みを活用することで、企業はDRと事業継続（BC）計画を強化することができきます。以下では、クロスクラウド・ディザスタリカバリ・アプローチを採用するメリットをいくつか紹介します。

各クラウド・プロバイダーの優れた機能の最適活用
今日、市場に存在するクラウド・プロバイダーは、それぞれ独自の機能とサービスを提供している。そのため、柔軟性、拡張性、収益の可能性がある。また、以下のことも可能になります。

●ベンダーロックインの回避： クロスクラウド・ディザスタリカバリにより、企業は1つのクラウド・プロバイダーの複雑さや制限に縛られることなく、より機敏に対応できるようになる。これにより、意思決定や技術的な適応において柔軟性が確保されます。
●両方のメリットを享受：例えば、ある企業が卓越したコンピュート・パワーとストレージ容量を理由にAzureに傾倒するかもしれません。同時に、AWSの処理能力の方が自社の要件に合っていると感じるかもしれません。クロス・クラウドのディザスタリカバリは、両者の強みを生かし、リソースの利用を最適化し、サービス・デリバリーを強化します。


確実な事業継続とディザスタリカバリ

デジタル時代において、データやサービスへの中断のないアクセスは譲れないものです。データをさまざまな地域やプラットフォームに分散することで、単一障害点が発生するリスクは大幅に減少します。この地理的およびプラットフォームベースの分散は、堅牢なDR計画の基礎となります。

データとアプリが複数のクラウド環境にまたがって保存されている場合、災害からの復旧スピードは飛躍的に速くなります。これにより、混乱を最小限に抑え、企業の評判と顧客の信頼を守ることができます。

クロスクラウド・リカバリーによるセキュリティ強化

セキュリティは、デジタル領域における企業の最重要課題です。クロスクラウド・リカバリー・モデルを採用することで、ITチームはカスタマイズされたソリューションを構築することができ、孤立したデータ・リポジトリを作成したり、誤って脆弱性を作り出したりする心配がなくなります。

異なるクラウド・プロバイダーは、独自のセキュリティ・メカニズムを提供する。複数のクラウドを活用することで、企業はさまざまな暗号化技術、脅威検出メカニズム、対応戦略の恩恵を受けることができます。

複数の環境でデータがミラーリングされることで、侵害などのセキュリティ・インシデントの影響は弱まります。マルチクラウド・アプローチは、1つの環境が侵害された場合でも、データの完全性が他の環境でも維持されることを保証し、追加の保護レイヤーを提供します。

コンプライアンスと規制基準への対応

特定の分野では、コンプライアンスは単なるベストプラクティスではなく、必須です。特に公共機関や金融機関では、データ保護に関する厳しい規制があるためです。マルチクラウド・アプローチは、当然ながら多様なストレージを提供し、データの冗長性とフェイルセーフ・リカバリー・メカニズムを義務付ける基準の遵守を容易にします。

クラウド・コンピューティングの黎明期にはシングル・クラウド・ソリューションが主流でしたが、将来は間違いなくクロス・クラウド・リカバリーが主流になるでしょう。柔軟性と堅牢性を兼ね備え、データの完全性とセキュリティを維持しながら、中断することなくサービスを提供することができます。

クロス・クラウドDRの導入と実用性における課題

複数のクラウドプロバイダーにまたがってリソースを利用することには、いくつかの利点がある一方で、企業にとって特有のハードルもあります。ここでは、これらの課題について詳しく考えてみます。

複雑性

マルチクラウド・アプローチは、本質的にデータとアプリケーションの管理に複雑なレイヤーを追加します。

データ管理の問題

企業がデータセットを複数のクラウド環境に分散するにつれ、データを追跡、同期、管理する能力は飛躍的に難しくなります。多様なソースからのデータを統一されたデータレイクやリポジトリに統合することは、非常に大きなタスクとなります。プラットフォームによってデータモデルやフォーマットが異なることが、このプロセスをさらに複雑にしています。

セキュリティとライフサイクル管理

クラウドプロバイダーによって、セキュリティプロトコルやデータ管理手法が異なることが多くあります。これらの多様なプラクティスを整合させ、一貫性のあるセキュリティとデータ・ライフサイクル戦略を構築するのは大変な作業になります。

専門知識の格差

●クラウドの専門知識： マルチクラウド環境の管理には高度な専門知識が必要です。複数のクラウドプラットフォームに関する包括的な知識を持つ専門家を見つけるのは難しものがあります。
●ITとDevOpsの学習曲線：チームは、各クラウド・プロバイダーの異なる方法論、プロビジョニング・ポリシー、ガバナンス構造に慣れなければなりません。そのため、リソースが不足し、展開のタイムラインが延びる可能性があります。

クラウドコスト

クロス・クラウドDRの財務的な影響は、さまざまな理由で複雑です。

コスト見積もりの課題

複数のクラウド環境で運用することは、各プロバイダーのコストを管理・分析することを意味します。そのため、クラウドの支出を統合的に把握するのは手間がかかります。

価格モデルの限界

従量課金の価格モデルは拡張性と柔軟性のために設計されていますが、これを複数のクラウドにまたがって活用するのは複雑な場合があります。マルチクラウド環境では、需要に応じてリソースを増減させることは、より複雑でコストがかかります。

エグレス(EGRESS)費用

マルチクラウド戦略に関して見落とされがちなコストの1つが、クラウド・エグレス料金です。これは、あるクラウド・プロバイダーのシステムから別のシステムにデータを移動する際に発生する料金でもあります。データ量にもよりますが、これらの料金はすぐにかさみ、マルチクラウドDR戦略の全体的なコスト効率に影響を与えます。

クロスクラウド・ディザスタリカバリには否定できないメリットがある一方で、企業は関連する複雑さとコストを認識しておく必要があります。これらの課題に対する利点のバランスを取るには、慎重な計画、ビジネス要件の理解、専門家の指導が必要です。

N2WSのクロスクラウド機能

ますます複雑化し、多様化するクラウド環境の中で、企業はデータのセキュリティとコスト効率を確保しながら、クロスクラウド運用を簡素化するツールを常に求めています。N2WSは、最新のクロスクラウド機能でこの分野をリードしています。

AWSバックアップのAzureへのアーカイブ

N2WSは、AWSのバックアップを直接Azureにアーカイブするという重要な機能を導入しまた。これは、企業のディザスタリカバリとデータアーカイブ戦略の要として機能し、2つの主要なクラウドプロバイダ間の橋渡しを提供します。

データ保護の強化

スナップショットアーカイブ
N2WSにより、企業はAWSインスタンスとボリュームからAzureストレージアカウントに直接スナップショットをアーカイブできる。

●データライフサイクル管理（DLM）： このツールは、AWSからAzureリポジトリへのDLMのシームレスな移行を容易にします。ここでの重要な特徴は、追加のセキュリティレイヤーとして不変性を組み込んでいることです。
●不変性（イミュータブル）： AzureのLease Blobを活用することで、オリジナルデータを所定の期間不変にすることができ、その完全性を確保し、改ざんから保護することができます。


包括的なバックアップ管理

N2WSのAWSバックアップ管理アプローチは、堅牢で総合的です。

●自動移行： AWSバックアップは、まずAzureストレージに移動され、その後、より低温のAzureストレージ層に移行され、その後、イミュータブル化されます。

●ユーザーフレンドリーなインターフェイス： この複雑なプロセスは、N2WSの一元化されたダッシュボードでシームレスに管理され、バックアップの表示と管理を一枚のガラスで行うことができます。

●多層的なセキュリティ： AWSが危険にさらされても、データはAzureで安全に保護されます。異なるクラウドプロバイダーに移行する固有のセキュリティだけでなく、データの不変性というレイヤーが追加されたことで、潜在的なハッカーはデータへのアクセスや改ざんにおいて無敵の挑戦に直面することになります。


GRC標準への適応

N2WSのクロスクラウド機能により、企業は厳格なガバナンス、リスク、コンプライアンス（GRC）要件を満たすことができます。企業は今後ますます、特定のデータセットを複数のクラウドにまたがって保存する必要が出てきますが、N2WSはそのための道を開きます。

コストの最適化

AWSとAzureのどちらもイングレス料金を徴収しませんが、企業は両プラットフォームで発生するイグレス料金に注意する必要があります。例えば、AzureのUS East Regionから500GBを転送すると43.07ドルかかりますが、AWSのS3から同じ操作を行うと44.91ドルになります。これはわずかな差に見えるかもしれないが、クロスクラウドオペレーションを理解し最適化することの重要性を強調しています。

このコスト構造に基づけば、Azureでデータをリストアする方がコスト効率が高く、N2WSが提供する洞察によって、企業がどのような戦略的決定を下せるかが浮き彫りになります。

N2WSの最新のクロスクラウド機能は、企業のマルチクラウド運用の見方と管理方法に革命を起こすことを確約してます。AWSとAzureのギャップを埋めることで、N2WSは多層的なデータ保護を提供し、最新のクラウドツールキットに不可欠なツールと位置づけられます。

クラウド・コンピューティングは、絶え間ない技術革新によって進化

AWSやAzureのような単一のクラウド環境における従来のディザスタリカバリ手法は、安定性を提供してきたかもしれないが、地域特有の脆弱性によるギャップも浮き彫りにしてきました。このようなギャップに対処するため、クロスクラウド・ディザスタリカバリがタイムリーな答えとして登場しました。このアプローチにより、企業は複数のクラウドプロバイダーの総合力を活用できるようになり、耐障害性が向上し、異なるリージョンやプラットフォームに分散されたオペレーションが確保されるため、障害発生ポイントを減らすことができきます。

しかし、クロス・クラウドのパラダイム・シフトに課題がないわけではありません。マルチプラットフォームのデータ管理の複雑さからコストの予測不可能性まで、確かに大きなハードルがあります。幸いなことに、N2WSはこれらのギャップを埋めるために設計されたソリューションです。

AWSのバックアップアーカイブをAzureに合理化し、データの不変性などの堅牢な機能を導入することで、N2WSは企業にとって保護シールドとコスト最適化ソリューションの両方の役割を果たします。クラウド環境が進化し続ける中、N2WSのようなツールは、デジタル時代に弾力的で前向きであり続けることを目指す組織にとって極めて重要です。

クロスクラウド時代をリードしたいとお考えなら、N2WSがどのようにディザスタリカバリ戦略を強化し、今後の課題とチャンスに備えることができるかをご確認ください。

タグ: , , ,

AWSストレージ・コストのナビゲーション： S3ストレージティアの選択でよくある落とし穴を避ける

投稿日: 2024年1月27日 クライム
AWS

クラウドをより賢く選択するためにはAWS S3ストレージの階層の決定が鍵

クラウドストレージに関して、AWSはS3ストレージティアで様々なオプションを提供している。各階層は異なるユースケースと予算制約に対応するように設計されています。しかし、これらの選択肢を色々とナビゲートすることは、迷路を歩くようなものです。

バックアップ戦略についての議論は必然的にストレージの検討に変わります。重要な質問は、「データの保存期間はどのくらいですか？」です。

最も一般的な回答は 「30日 」でしょう。しかし「なぜ30日なのか？」とさらに質問すると、この期間は恣意的に見えるが、多くの企業にとっては意図的な選択なことが多くあります。その理由は包括的なテーマは予算の制約なことがほとんどです。

ここでの視点はもはや時間ではなく、金銭的な制約についてです。

もちろん、予算は意思決定に欠かせない要素です。しかし、しばしば見落とされがちなのは、中間地点、つまり金銭的制約とその他の重要な要件の両方に対応するソリューションを見つける可能性にあります。利用可能な選択肢を理解し、それらが時間とコストのバランスにどのように影響するかを理解することが不可欠です。この知識は、予算の制限だけでなく、運営上のニーズにも沿った、十分な情報に基づいた意思決定を行う上で極めて重要です。

ここでは、ユーザがS3ストレージ・ティアを選択する際に遭遇しがちないくつかの見落としと、十分な情報に基づいた決定をする方法を紹介します。

アクセス頻度の見落とし

AWS S3はStandard、Infrequent Access (IA)、Intelligent Tiering、One Zone-IAのような階層を提供し、それぞれアクセス頻度に基づいて異なる価格設定モデルを持っています。

よくある間違いは、IAやOne Zone-IAのような安価な階層を頻繁にアクセスするデータのために選択することです。

データに頻繁にアクセスする場合、これらのコストはすぐにかさみ、長期的にはスタンダード・ティアの方が費用対効果が高くなります。

データ検索時間の無視

長期的なデータ保存には、GlacierとDeep Archive Glacier階層が最も低いストレージコストを提供します。しかし、データ検索にかかる時間は数分から数時間と長くなります

ユーザはこの点を考慮しないことがあり、アーカイブされたデータに素早くアクセスする必要があるときに不満を感じることになります。データ検索のニーズに合わせて選択することが重要です。例えば、Glacierは数分以内に必要なデータに適しており、Deep Archiveは滅多に必要ではないがコンプライアンス上長期保持しなければならないデータに最適です。

データ転送とリクエスト・コストの軽視

ストレージのコストばかりが注目されがちですが、データ転送やリクエストのコストも見逃せません。これらのコストはティアやリージョンによって大きく異なります。

例えば、AWS S3からインターネットにデータを転送する場合、コストが発生し、これはデータ量が大きい場合、相当な額になります可能性があります。同様に、S3バケットへのPUT、COPY、POST、LISTリクエストのような操作は、独自の価格設定を伴います。ユーザは、予期せぬ出費を避けるために、これらのコストを考慮に入れておく必要があります。

バージョニングのコストの過小評価

オブジェクトの複数のバージョンを同じバケットに保持するS3のバージョニング機能は、データの整合性とリカバリのために信じられないほど便利です。しかし、オブジェクトの各バージョンは別個のエンティティとして保存され、ストレージコストの一因となります。ユーザは、データの複数のバージョンを保存することに関連する追加コストを考慮せずに、バージョニングを有効にすることがあります。

ライフサイクルポリシーを忘れて

AWS S3のライフサイクルポリシーは、階層間のデータの移動や削除のスケジュールを自動化することができ、大幅なコスト削減につながります。しかし、ユーザはこれらのポリシーなしでS3バケットを設定することが多く、必要以上に高価な階層にデータを残したり、不要なデータを蓄積したりして、コストを膨れ上がらせます。


AWSのS3ストレージ階層は、その多様な価格設定と機能により、多様なストレージニーズを満たす柔軟なソリューションを提供しています。しかし、コストを最適化し、効率的なデータ管理を行うためには、各階層のニュアンスを理解することが重要です。これらのよくある落とし穴を避けることで、ユーザは予算の制約から外れることなく、AWSの強力なストレージ機能を最大限に活用することができます。

タグ: , ,

ハイブリッド クラウドとは？

投稿日: 2024年1月23日 クライム
AWS Azure Hyper-V VMware クラウド・仮想インフラ

パブリック クラウド、プライベート クラウド、オンプレミス リソースを組み合わせた構成のクラウド コンピューティング アーキテクチャを、ハイブリッド クラウド アーキテクチャと呼びます。ハイブリッド クラウドでは、データとアプリケーションを異なるタイプのリソースから共有できるようにすることで、個々のデプロイメントの特長を活かしたアーキテクチャの最適化が可能になります。

ハイブリッド クラウド アーキテクチャを採用している企業は、ワークロードの要件、規制やコンプライアンスの要件、技術的な要件や制約、セキュリティやコストなどの優先事項に応じて、データとアプリケーションを複数ロケーションでホストすることができます。

したがって、ハイブリッド クラウド アーキテクチャでは、異なる要素をどこに配置し、どのように管理し、モニタリングするかを決めるためのツール、サービス、ガバナンスのしくみやプロセスが特に重要になります。さらに、異なる環境を連携させるためのネットワーキング テクノロジーは、ハイブリッド クラウド アーキテクチャの根幹を成す骨組みとなります。

そして、異なる環境を統一性をもって一元管理できるようなプラットフォームもハイブリッド クラウド アーキテクチャでは重要な役割を担います。代表的なツールとしては、ハイブリッド インフラストラクチャ全般にわたるオーケストレーションとワークロードのポータビリティ（可搬性）を可能にするKubernetesが挙げられます。

仮想化とコンテナ化

一般的にハイブリッド クラウド アーキテクチャでは、VMwareによる仮想化や、Dockerを用いたコンテナ化など、コンピューティング リソースを抽象化するテクノロジーの運用が成功の鍵を握ります。たとえば、VMwareでは、サーバーをハイパーバイザーを通じて仮想化し、複数の仮想マシン（VM）を個々の用途に応じて別々に運用できるようにします。同様に、ワークロードのコンテナ化によるKubernetesクラスタでのサポートにもVMwareは対応しています。Kubernetesによるコンテナのオーケストレーションを複数の環境にまたがって抽象化し、効率化するツールとしては、Veeam傘下のKastenによるK10プラットフォームも注目されています。

ワークロードの可搬性

仮想化やコンテナ化は、ハイブリッド クラウド アーキテクチャにおいてワークロードの可搬性を確保する点でも非常に有効な技術です。実際に配置されている物理的な環境とは関係なく、アプリケーションとワークロードを異なる環境にまたがって柔軟に実行できるようにすることで、ハイブリッド クラウドの利点を維持しながら、インフラストラクチャを簡素化し、ユーザーの利便性を高めることができます。

オーケストレーションと自動プロビジョニング

ハイブリッド クラウド アーキテクチャでは、マネジメント プラットフォームを活用することで、リソースを効率的に管理し、プロビジョニングを自動化できます。異なる環境にリソースをニーズに応じて配置できるので、無駄を省いたり、事業規模の拡大に応じたスケーリングが可能になります。

ハイブリッド クラウド アーキテクチャの利点とは？

ハイブリッド クラウド アーキテクチャを採用することの主な利点を以下にまとめます。

  • クラウドへの移行を容易に

オンプレミスのみの環境からパブリック クラウドへの移行を目指す企業にとっては、ハイブリッド クラウドが中間モデルとして機能し、より効率的で円滑な移行が可能になります。

  • コストの削減

ハイブリッド クラウドではリソースの配置を最適化できるので、オンプレミスのみやパブリック クラウドのみの環境に比べ、コストを削減できる可能性が広がります。

  • コンプライアンスの徹底

機密データをオンプレミスに保持することで法令や規制の要件を満たしたり、データ主権を確保したりできます。

  • 既存アセットの有効利用

オンプレミスに既存するアセットをそのまま活用しながら、パブリック クラウドで新たなリソースを運用できるので、既存アセットが無駄になりません。

  • ワークロードの可搬性の確保

仮想化やコンテナの活用により、ワークロードを複数の環境にまたがって柔軟に運用できるので、デプロイメントの選択肢が増えます。

  • 障害復旧（DR）やレジリエンスの強化

地理的冗長性も含め、複数の環境へのデプロイメントが可能になるので、レジリエンスが高まり、事業継続および障害復旧（DR）計画を整備できます。

  • スケーラビリティの確保

各ワークロードに最適な環境を選択でき、必要に応じて自動的な拡張性（スケーリングやクラウド バースト）を実現できます。

ハイブリッド クラウドの課題

ハイブリッド クラウドには、上記のように多くの利点がありますが、導入のためには超えなければならないハードルも少なくありません。個々の企業が置かれた状況によっては、以下の点がハードルになると考えられます。

  • 環境の複雑さ

さまざまな環境にまたがって複数の要素が展開されるので、統合の複雑さは否めません。

  • 管理の透明性

オンプレミスのみのデプロイメントに比べると、外部でホストされるインフラストラクチャは、すべての要素を管理下に置いて完全掌握できるわけではありません。

  • パフォーマンス

ハイブリッドクラウドは基本的に分散型となるため、その分、ネットワークに負荷がかかり、パフォーマンスに影響する可能性があります。

  • セキュリティ

オンプレミスのみの運用に比べれば、外部の環境と連携するので、アクセスポイントの管理が重要になります。

  • 人材・スキル

統合を管理できるスキル、そのような人材が必要になります。

ハイブリッド クラウド アーキテクチャの実用例

プライベート クラウド、パブリック クラウド、オンプレミス リソースを組み合わせる方法は無数にあり、個々の企業のユースケース、要件、優先順位や制約に応じてアーキテクチャを柔軟に構成し、ニーズに合わせて運用することができます。以下に代表的なユースケースをいくつか紹介します。

  • バックアップと障害復旧（DR）

パブリック クラウドのIaaS（Infrastructure as a Service）は、オンプレミス リソースからのデータをバックアップして、障害復旧（DR）に備えるための効率的な手段となります。

  • クラウド バースト

オンプレミスでの運用がピークに達したときに、超過ワークロードをパブリック クラウドにプロビジョニングするしくみです。

  • ポリシーベースの配置

セキュリティ、コンプライアンス、レイテンシ、コストなどの要因にもとづいてルールを設定し、そのルールに沿ってデータとワークロードを配置します。

  • セキュリティ セグメンテーション

機密性の高いデータやアプリケーションをオンプレミスやプライベート クラウドでホストし、それ以外のワークロードをパブリック クラウドでホストします。

以上、ハイブリッド クラウド アーキテクチャの特徴や種類、利点と課題、ユースケースを簡単に紹介してまいりました。移行やインフラストラクチャの拡大を検討する際には、利点と課題を自社のニーズに照らし、戦略的に取り組むことが何より重要になります。

今あらためて考える、クラウドと仮想化

投稿日: 2023年12月22日 クライム
VMware クラウド・仮想インフラ

日本では、DXと言えばクラウド、というイメージが定着している感があります。「クラウド」と名のつくものを導入すればデジタル化が達成されるかのような印象を持たせるテレビコマーシャルもよく見かけます。そのようなITサービスの広告が、いったい何をもって「クラウド」と言っているのか、あらためてCM動画などを検索して見直してみると、どうやら「インターネット」のことなのではないかという気がしてきました。

いやいや、何を今さら、インターネットを導入して会社のDXを促進！なんて戯けたことを抜かしていたら世界中の笑いものになってしまうので、「クラウド」という言葉の裏にはもっと深い意味があるはずです。そこは絶対にあるはずなのですが、でも「クラウド」を「インターネット」に置き換えても、すっと理解できてしまうのは気のせいでしょうか。

テレビCMなどは一般大衆が見るものなので、あえてシンプルにわかりやすく、クラウドの具体的な内容に深く触れないようにしたら「クラウド＝インターネット」になってしまうだけなのかもしれません。英語のジョークでも、「The cloud is just someone else’s computer（クラウドは単なる他人のコンピュータ）」という有名なフレーズがあって、Tシャツやマグカップのロゴになったりしています。

つまり、具体的に深くは説明したくないけれど「クラウド」という言葉は強調したいCMのような媒体では、クラウドは他所のコンピュータにインターネットで接続するだけ！のような印象になってしまいますが、それは穿った見方というものです。「クラウド」と謳っているからには、きっとそこにはいろんな便利なサービスが詰め込まれているんだろうな、と素直にざっくり、暗黙のうちに理解すべきなのでしょう。

では、単なるインターネット経由のサーバーアクセスではなく、実際にはいろいろあるクラウドには、いったい何があるのでしょうか。CMなどの広告からは伝わってこないけど、簡単に言えば、「社内のIT環境でできることをインターネット経由でできるようにする」ということだと思います。ただ、それだけだと、まだ結局「クラウド＝インターネット」になってしまうので、そこで重要なのは、「社内にその環境がなくてもインターネット経由でできる」という点です。

社員一人ひとりがローカルでは持っていないソフトウェアをインターネットで使えるようにしたり、パソコン環境をインターネット経由で提供したり、IT環境そのものをインターネット経由で実現したりするからこその、単なるインターネットではない「クラウド」です。

と、ここまで考えてみると、DXを推奨するCMが実際に強調すべきキーワードは「クラウド」ではなく、「仮想化」なのでは？？？ 仮想化のかの字も出て来ないのが不思議なくらいです。

歴史的に言えば、クラウドがバズワードになるよりも前に、まずIT企業は仮想化を導入していたと思います。個人的な経験では（十数年前の米企業では）この手のテクノロジーに最初に遭遇したのは、従来、複数のサーバーをテスト環境ごとに分けていたのを、物理的に分けるのは無駄なので仮想的に分けるようになったときだと記憶しています。やがて、社員一人ひとりの開発環境も、各自のパソコンに設定するのは手間もコストも無駄なので、サーバー上に各自の環境を仮想化するようになりました。それをインターネット経由で行うようになった頃、世間でも徐々に「クラウド」という言葉が叫ばれるようになってきました。

だから、日本企業にDXを推奨するようなCMも、「クラウド」を強調するよりも、まず「仮想化」を強調すべきなのでは？と思ってしまうのですが、今は時代が違います。クラウドがすっかり定着しているのだから、仮想化を意識させずに「クラウド」という言葉を前面に押し出して、クラウドサービスの中でそれとなく仮想化を駆使しながらも、それをユーザーが意識しないで済むようなパッケージが普及している、と見るべきなのかもしれません。

でも、それは一般大衆向けの場合です。企業のIT担当者は、やはり今でも、まず「仮想化」を意識しながらDXを進めるべきだと思います。その際、仮想化のメリットとクラウドのメリットを別々に整理して、自社の優先順位を考慮すべきです。

仮想化のメリット

仮想化の最大のメリットは物理リソースの節約です。リソースを有効利用できるので、この用途ではスペースを余らせているのに、他の用途では足りないのでもう1台購入、なんて無駄が省けます。これは同時に、物理リソースの一元管理も可能にします。複数サーバーを個々にアップデートする手間もなくなるし、各ユーザー環境を仮想化してIT担当者が管理する場合は、セキュリティも強化できます。ユーザーが勝手に無許可アプリをダウンロードしたり（シャドウIT）、セキュリティアップデートを怠ったりすれば、一人のユーザーの不手際が会社全体に影響を及ぼすなんてこともあります。実際、昨今のランサムウェア被害の多くは、それが主要な原因の1つだと報じられています。IT担当者が各ユーザー環境を一括管理できることの重要性は、年々増しています。

クラウドのメリット

それに対して、クラウドの最大のメリットの1つは、拡張性（スケーラビリティ）です。ビッグデータというバズワードは最近はあまり聞かなくなりましたが、AIの普及も手伝って、企業データの肥大化はますます進んでいるに違いありません。長い目で見れば、将来的な事業規模の拡大に合わせたスケーリングも考慮しなければならないし、オンプレミス環境だけの対応では限りがあります。クラウドだと、地理的、時間的制約がなく、いつでもどこでもアクセス可能になるので、スケーラビリティに加え、アクセシビリティも向上します。さらに、セキュリティにおいても、オフサイトのバックアップや障害復旧（DR）の側面から、仮想化とは違った意味で重要な役割を果たします。セキュリティのアップデートや管理をクラウドプロバイダに任せられる点も利点と言えるでしょう。

ただし、他者に依存することによって、セキュリティに不安を感じる企業も少なくないようです。管理を任せること自体よりも、ベンダーに縛られることのほうが、将来的な柔軟性が制限されるリスクを孕みます。オンプレミス環境や複数クラウドを組み合わせたハイブリッド環境のほうが合理的だと判断する企業が増えているのも頷けます。

クラウド＋仮想化

いずれにせよ、闇雲にクラウド化を進めるのではなく、一度立ち止まって、オンプレミス環境だけで足りるのか、クラウドへの移行が重要なのか、それらを組み合わせるべきか、個々の選択肢のメリットとデメリットを自社の要件に照らして検証することが大切です。その際には、オンプレミスvsクラウドの比較だけでなく、「仮想化」もクラウドと切り離して、個別にその利点を検証してみてください。得てして、「クラウド」そのものよりも「仮想化」のほうがDXの根本を支えていて、そのうえで「仮想化＋クラウド」への進化が理に適っている場合が少なくないはずです。

エンタープライズ・ハイブリッド・クラウド環境とは？

投稿日: 2023年12月15日 クライム
Hyper-V クラウド・仮想インフラ

エンタープライズ・ハイブリッド・クラウド環境は、ITインフラを確立するための業界標準となっています。エンタープライズ・ハイブリッド・クラウドは、パブリック・クラウドとプライベート・クラウドの両方を組み合わせることで、最終的に企業のITリソースの管理を簡素化できるため、ますます人気が高まっています。

企業がハイブリッド・クラウドのインフラ・モデルを採用し続けるにつれ、その市場規模は指数関数的に拡大しています。業界アナリストによると、2026年までに世界のハイブリッド・クラウド市場は1450億米ドルに達すると推定されています。そこでここでは、ハイブリッド・クラウドとは何か、そしてハイブリッド・クラウドがコスト削減とシームレスな拡張にどのように役立つのかについてご紹介します。

ハイブリッド・クラウドとは？

ハイブリッド・クラウドとは、企業がオンプレミスのデータ・センターやエッジ・ロケーションを含むプライベート・クラウドとパブリック・クラウドを組み合わせたり利用したりするITインフラの一種です。こうすることで、企業や個人は、異なるコンピューティング環境間でワークロードを管理・移行し、コストを削減し、効率性とセキュリティを高め、デジタルトランスフォーメーションの取り組みを強化することができます。つまり、事実上、オンプレミスのインフラをパブリッククラウドに拡張するようなもので、企業の拡張能力を高めることができます。

エンタープライズ・ハイブリッド・クラウドのコンセプトは、ITサービスやリソースは偏在するものでも単一なものでもないという、現代的な考え方を強制するものです。ハイブリッド・クラウドは、さまざまなクラウド環境のリソース、アプリケーション、サービス、ハードウェアをダイナミックかつ複雑に組み合わせたものであり、プロバイダーからサービスとして購入したり、個別に構築したりすることができます。

ハイブリッド・クラウド環境はどのように機能するのか？

プライベート・クラウドとパブリック・クラウドには、それぞれ長所と短所があります。そこで、ハイブリッド・クラウドの背景にある考え方は、両方の長所を活かしつつ、短所を最小限に抑えることです。そのため、企業はその時点でのビジネスニーズに応じて、ワークロードやアプリケーションをオンプレミスまたはパブリッククラウドにデプロイすることを決定できます。これは、プライベート・クラウドやパブリック・クラウドを個別に利用するのでは実現できない、比類のない柔軟性につながります。

そのため、ローカルまたはオンプレミスのインフラ上で、企業はミッションクリティカルなアプリやワークロードを保持し、そこで直接制御したり、機密情報を適切な方法で管理したりすることができます。 パブリック・クラウドは、企業のITインフラにおいて異なる役割を果たします。パブリック・クラウドは、企業がそれほど重要でない、あるいは機密性の高いアプリやワークロードをデプロイできる環境です。また、ビジネスを低コストでシームレスに拡張するのにも役立ちます。

エンタープライズ・ハイブリッド・クラウドの構成要素

ハイブリッド・クラウド・インフラの可能性を最大限に活用するには、この環境を実現するすべてのコンポーネントを理解することが重要です。ハイブリッド・クラウドの構築を成功させるには、4つの主要コンポーネントが必要です。

  1. データ・センターなどのオンプレミスまたはプライベート・コンピューティング・リソース（通常、サーバー、ストレージ・システム、ネットワーク・インフラを含む）
  2. Microsoft Azure、Amazon Web Services、Google Cloud Platformなどのパブリック・クラウド・インフラ
  3. ハイブリッド・クラウドのプライベート・クラウド環境とパブリック・クラウド環境への適切なネットワーク接続
  4. プライベート・クラウドとパブリック・クラウドの要素を、高度に自動化されたポリシー駆動型の統合環境として管理するためのソフトウェア・プラットフォーム

パブリッククラウドとプライベートクラウドの比較

パブリック・クラウドのインフラストラクチャでは、サーバーとストレージを含むクラウド・リソースは、サード・ストレージ・プロバイダーによって所有・運用される。サービスはインターネット経由で提供され、ウェブ・ブラウザを通じてアクセスします。つまり、パブリック・クラウドのハードウェア、ストレージ、ネットワーク機能は、サービスを利用するすべての人の間で共有されます。

一方、プライベート・クラウドは、1つの企業専用にコンピューティング・リソースを提供します。組織内のオンサイトでホストすることも、サードパーティのサービス・プロバイダーがホストすることもできます。そのため、必要に応じてリソースを簡単に管理できます。プライベート・クラウドは、ソフトウェアとハードウェアを単独で管理したい企業がよく利用します。

ハイブリッド・クラウドの利点と欠点

他のテクノロジーと同様、ハイブリッド・クラウドにも利点と欠点があります。ユーザのビジネスが何を得ることができるのかを理解するために、それらを詳しく見ていきましょう。

ハイブリッド・クラウドの利点

企業がハイブリッド・クラウドの導入を決定する主な理由の1つは、セキュリティ上の理由です。厳重なセキュリティが必要なアプリやワークロードは、すべてオンプレミスのプライベート・クラウドに置いておきます。

コンプライアンスの強化も、ハイブリッド・クラウドのメリットだ。組織がサーバーを所有する場合、厳格な要件に準拠する必要があるデータやアプリはすべてプライベート・サーバーに保管するようにできます。

ハイブリッド・クラウドでは、新しいコンピューティング・リソースを即座にプロビジョニングして展開できるため、新製品やサービスの市場投入までの時間を短縮できます。さらに、需要の増加に合わせてコンピューティング・リソースを追加することも容易です。

ハイブリッド・クラウドは従来のデータセンターよりも稼働時間が長く、必要に応じて高性能なコンピューティング・リソースにアクセスすることも容易です。

また、企業のハイブリッド・クラウドは、ユーザがインターネットに接続されたデバイスからクラウド・サービスにアクセスすることを可能にし、従業員の機動性を高めます。

ハイブリッド・クラウドの欠点

ハイブリッド・クラウド・インフラを導入することは、バラ色ばかりではありません。パブリック・クラウドとプライベート・クラウドの両方の要素を含むハイブリッド・クラウド環境は複雑なため、すぐに導入するのは難しいです。また、インフラを確実に維持するためには、専門性の高い従業員が必要になります。

企業のハイブリッド・クラウド利用事例

ハイブリッド・クラウドには数多くのユースケースがあり、企業がハイブリッド・クラウドを導入する理由はさまざまです。エンタープライズ・ハイブリッド・クラウドの最も一般的なユースケースをいくつか見てみましょう：

需要の増加

多くの企業、特にeコマース企業では、特定のシーズンになるとサービスの需要が急増します。このような時期にプライベート・クラウドで運用するのは難しいです。そこで、追加のトラフィックをすべて処理するには、パブリック・クラウドのサービスを活用するのが望ましいです。こうすることで、企業は資金繰りに苦しむことなく、季節ごとの需要に対応することができます。

地理的冗長性

プライベート・クラウドのインフラで地理的冗長性を設定すると、資本支出や諸経費がほぼ2倍になるため、非常に高くつく可能性があります。しかし、パブリック・クラウドは、冗長性、データ・バックアップ、ミラーリングを提供できることでよく知られています。

規制コンプライアンス

機密データには、組織によって異なるコンプライアンス規制が常につきまといます。ハイブリッド・クラウドを運用することで、これらの規制を遵守し、罰金を回避することができます。例えば、ファイナンス・アプリケーションの中には、データをオンプレミス・インフラストラクチャにのみ保存することを義務付けているものもあります。

オフサイト・バックアップ

ハイブリッド・クラウド・インフラは、企業のオフサイト・バックアップに役立ちます。パブリック・クラウドは、機器の故障時にオンプレミス・データのバックアップ・サイトとして機能し、ビジネスの継続性を促進するからです。

StarWindは、エンタープライズ・ハイブリッド・クラウドの構築にどのように役立ちますか？

StarWind VSAN for Hyper-Vを使用することで、企業はオンプレミスの仮想化ワークロードをデータセンターからAzureパブリッククラウドに移行するハイブリッドクラウドソリューションを構築できます。その実装により、オンプレミスのサーバーとAzure VMを、よく知られたHyper-Vフェイルオーバークラスターでアセンブルすることが可能になります。ハイブリッドクラウドは、StarWind Management Console、Hyper-V、およびSCVMMを使用してオーケストレーションされるため、Azureプラットフォームの経験は不要です。

StarWind Virtual SAN for Hyper-V は、ロケーション間でデータをレプリケートする、可用性の高い共有ストレージを分散します。アクティブ・アクティブ・ストレージを提供するStarWindは、Azureパブリッククラウドに耐障害性の高いディザスタリカバリサイトを提供し、要求されるRTOとRPOを満たします。

結論 :企業にハイブリッド・クラウドは必要か？

上記で見てきたように、エンタープライズ向けハイブリッド・クラウドは、プライベート・クラウドとパブリック・クラウドの機能を組み合わせることで、企業に両方の長所を提供します。ハイブリッド・クラウドは、パブリック・クラウドの拡張性とプライベート・クラウドの強化されたセキュリティを提供します。

しかし、ハイブリッド・クラウド・インフラがもたらすメリットがすべてあるとはいえ、ビジネス全体の機能に影響を及ぼす可能性のあるテクノロジーをやみくもに導入するのは決して得策ではありません。したがって、ハイブリッド・クラウド・インフラを選択する前に、現在と将来の両方のビジネス・ニーズを考慮する必要があります。

FAQ

ハイブリッド・クラウドは安全か？

はい、ハイブリッド・クラウド環境は、特にセキュリティの原則と実践に重点を置いて実装された場合、安全でセキュアです。プライベート・クラウドの機能も備えているため、企業は機密情報をそこに保管することができます。しかし、他のIT環境と同様に、ハイブリッド・クラウドにもリスクがないわけではありません。ハイブリッド・クラウドのセットアップにおける安全性は、適切なテクノロジーを使用し、実装と管理におけるベスト・プラクティスに従うことの組み合わせにかかっています。

マルチクラウド、ポリクラウド、ハイブリッドクラウドの違いは何ですか？

いいえ、これらは同じではありません。マルチクラウドやポリクラウド環境とは、1つの組織でさまざまなベンダーのさまざまなパブリッククラウドを使用することを意味します。しかし、ハイブリッド・クラウドとは、ITインフラの一部としてプライベート・クラウドとパブリック・クラウドを運用することを意味します。

 

 

タグ: , , , ,

VSAN vs SAN: その違いは

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

急速に変化するデジタルの世界では、ビジネスを円滑に運営し、必要不可欠なアプリやサービスを滞りなく稼働させるために、ストレージ・ソリューションが欠かせません。ストレージの領域で著名なプレーヤは、従来型ストレージ・エリア・ネットワーク（SAN）と、それに対応する仮想SAN(Virtual SAN: VSAN)の2つのです。これらのソリューションはデータの保存、管理、アクセスのバックボーンとして機能するが、そのアプローチと機能は異なります。ここでは、仮想SANと従来型SANシステムのニュアンス、主な特徴、比較分析について掘り下げ、ストレージ・インフラについて十分な情報に基づいた決定を下すのに役立つことを期待します。

VSAN vs SAN

仮想SAN (VSAN) は？

仮想ストレージ・エリア・ネットワーク（VSAN）は、iSCSIやファイバー・チャネルなどのプロトコルを使用して、ハードドライブやソリッド・ステート・ドライブなどの複数の物理ストレージ・デバイスからストレージ・リソースの仮想化プールを作成するソフトウェア定義ストレージ・ソリューション(SDSS)である。こうすることで、データセンターやクラウド環境において、仮想マシン（VM）やアプリケーションが後者を利用できるようになります。この仮想化されたストレージは、異なるVMやアプリケーションのストレージ・ニーズを満たすために動的に割り当てられ、管理されます。要するに、仮想SANは、VMware vSphere、Microsoft Hyper-V、KVM、Citrix（旧XenServer）などの一般的なハイパーバイザーとシームレスに統合できる仮想ストレージアプライアンスとして機能します。この統合により、企業は構造化データ用に最適化されたブロックモード・ストレージ・ソリューションを構築することができます。複雑なハードウェア・コンポーネントで構成されることが多い従来のSANとは異なり、VSANは、互換性のある仮想化ホスト環境を実行していれば、業界標準のx86サーバに導入可能で、より合理的なアプローチを提供します。

Software-Definedストレージ技術を使用することで、VSANは物理ストレージを抽象化・仮想化し、ストレージ管理の柔軟性と効率性を向上させます。仮想化およびハイパーコンバージド・インフラストラクチャ環境におけるデータ・ストレージと管理を強化するためによく使用されます。

従来型SANは？

従来のストレージ・エリア・ネットワークは、しばしばSANと呼ばれ、長年データ・ストレージの世界では定番となっています。SANは、ストレージデバイスをサーバーに接続する専用ネットワークとして動作し、集中型のストレージ管理とデータアクセスを提供します。SANのセットアップでは、ストレージ・デバイスは通常サーバーから分離されており、専用のハードウェアを介してアクセスされます。

SANは従来、その信頼性、パフォーマンス、ミッションクリティカルなアプリケーションへの適合性で知られてきました。しかし、特殊なハードウェア・コンポーネントが必要なため、管理が複雑で、導入コストが高くつくこともあります。

VSANの主な特徴

1. データ遅延の削減： VSANは外部ネットワーク・ストレージの必要性を排除し、データ・レイテンシーを削減し、レスポンス・タイムを短縮します。これは、データへの低レイテンシーアクセスを要求するアプリケーションにとって特に重要である。

2.データ保護の強化： 分散アーキテクチャにより、VSANは自動的にデータを他のサーバに複製し、堅牢なデータ保護を提供します。この保護機能は、サーバーの障害に対する保護にも拡張され、データの整合性と可用性を保証します。

3.簡素化されたストレージ管理： VSANは集中管理を提供し、ストレージリソースの管理とヘルスモニタリングを合理化します。この管理の容易さは、プロビジョニングとメンテナンスにおける効率性の向上とミスの減少につながります。

4.コンテナや仮想マシンとの統合： VSANは、コンテナやVMを含む仮想化技術とシームレスに統合します。この汎用性により、企業は同じストレージインフラ上で従来のアプリケーションと最新のアプリケーションの両方を実行することができ、柔軟性と適応性が向上します。

5.コスト効率： 既存のサーバ・ローカル・ストレージとフラッシュ・コンポーネントを仮想化プールにプールするVSANの機能は、コスト削減につながります。この費用対効果により、予算をかけずに効率的なストレージ・ソリューションを求める組織にとって魅力的な選択肢となります。

SANの主な特徴

1.高性能： 従来のSANは、高速データアクセスと低レイテンシーを提供することに優れており、パフォーマンスが重視されるアプリケーションに適しています。また、信頼性と一貫性の点でもよく選ばれています。

2.データ保護： SANは、RAID構成やフェイルオーバー機能など、堅牢なデータ保護機能で知られています。これらの機能により、データの整合性が確保され、ハードウェア故障時のダウンタイムが最小限に抑えられます。

3.構造化されたワークロードへの展開： SANは、構造化されたデータ・ワークロードの処理に理想的であるため、データ処理要件が厳しい環境に適しています。

4.クリティカルなワークロードのサポート： 従来のSANは、ミッションクリティカルなワークロードを効率的に処理できるため、重大なシナリオでも中断することなく運用できます。

5.エンタープライズグレードの機能： SANにはエンタープライズグレードの機能が搭載されていることが多く、複雑なストレージニーズを抱える大企業に適しています。これらの機能には、高度なセキュリティ、拡張性、包括的な管理ツールが含まれます。

VSANとSANのどちらを選択するかは、組織固有の要件と優先順位に合わせる必要があります。VSANはシンプルさ、拡張性、コスト効率を提供し、最新のデータ駆動環境にとって魅力的な選択肢となります。ストレージを個別のハードウェア・コンポーネントに分離する従来のSANとは対照的に、VSANは独自のアプローチを採用しています。管理者はストレージをサーバに分散し、これらのリソースを論理的に統合することができます。一方、SANはハイパフォーマンス・シナリオに優れており、ミッション・クリティカルなワークロードに適しています。最終的には、組織固有のニーズと長期的なストレージ戦略によって決定します。

StarWind Virtual SAN を選択する理由

StarWind Virtual SAN（VSAN）は、エンタープライズ ROBO、中小企業、およびエッジ環境の特定のニーズに対応し、最良の選択肢として際立っています。複雑なハードウェア構成に依存する従来の SAN ソリューションとは対照的に、StarWind Virtual SAN は「ソフトウェアがハードウェアを置き換える」アプローチを採用しており、ハイパーコンバージドインフラストラクチャ（HCI）の不可欠な一部となっています。

StarWind Virtual SAN は、クラスタ内のフラッシュとディスクのリソースを組み合わせて、すべてのホストがアクセス可能な仮想共有ストレージ・プールを作成することで、ストレージに革命をもたらします。この革新的なアプローチにより、仮想化に伴うコストと複雑性が大幅に削減され、SAN、NAS、DAS などの物理的な共有ストレージが不要になります。その結果、合理的でコスト効率に優れたソリューションとなり、中小企業など予算の制約やリソースの制限に直面している組織にとって理想的な選択肢となります。2009年以来の実績により、StarWindのVirtual SAN製品は63,800社以上の企業から信頼を得ています。

結論

VSAN対SANの継続的な議論では、どちらにもメリットがあり、多様なストレージ要件に対応できることを認識することが不可欠です。最終的には、予算、スケーラビリティのニーズ、パフォーマンス要求、インフラの複雑さ、ストレージ管理における柔軟性とシンプルさをどの程度重視するかといった要因によって決定されます。デジタル環境が進化するにつれて、VSANとSANのどちらを選択するかについて十分な情報を得ることは、データ主導の今日の世界で競争力と効率性を維持するためにますます重要になっています。

タグ: , , ,

高可用性（HA) vs. フォールト・トレランス

投稿日: 2023年11月11日 クライム
クラウド・仮想インフラ セキュリティ ディザスタ・リカバリ

高可用性（HA) とフォールト・トレランスの何が違うのか？

どのようなビジネスを経営しているにせよ、何らかのハードウェアとOS（またはハイパーバイザー）の上で稼働しており、ハードウェアやOSに障害が発生した場合、ビジネスのワークフローが滞る可能性があります。さらに、バックアップが利用可能であっても、復旧手順にはかなりの時間がかかり、収入と評判の両方でビジネス上の損失が発生する可能性があります。

ITインフラのダウンタイムのリスクを軽減する方法は、正確には2つあります： 高可用性（HA）とフォールト・トレランス(耐障害性:FT）です。残念なことにこの2つを多くの人がいまだにごちゃ混ぜにし続けていいます。そこで、HAとFTの両方がどのようなもので、どのような違いがあり、どちらがIT利用者にとって良いのかを考えてみましょう。


高可用性（HA)とは？

高可用性とは、コンポーネントに障害が発生した後、インフラが迅速に自己回復し、ほとんどの時間稼働し続ける能力のことです。HAシステムでは、フェイルオーバーに必要な短時間（数秒から数分）のダウンタイムが発生することがあるが、重要なのはデータが失われないことです。HA環境では、RPOはゼロ、RTOは数分に近いものです。クラウドサービスでは、99.9％（1年間のダウンタイムが約9時間）や99.999％（1年間のダウンタイムが約5分半）など、1年を通してサービスが利用可能な時間の割合で測定されることが多いことがあります。

実際のシナリオで例を挙げましょう。ハードウェアがクラッシュし、サービスが自動的に復旧するまで数分間オフラインになりました。この状況は喜ばしいものではありませんが、1～2分のダウンタイムがビジネスに影響を与える可能性は極めて低いでしょう。

高可用性の利点

●フォールト・トレランス・ソリューションと比較してコスト効率が高い。

●複雑性が低い。すぐに使えるHAを提供するベンダーはたくさんあります。また、DIY HAソリューションのためのフリー（またはオープンソース）ツールもあります。

●スケーラビリティ（拡張性）。ほとんどのHAソリューションはクラスタの概念を利用しているため、非HAインフラよりも拡張が容易。

●バックアップやディザスタリカバリのレプリケーションと比較して、RPOとRTOがはるかに優れている。

●人手を介さない自動サービス復旧が可能

高可用性の欠点

●故障したコンポーネントのサービス/アプリケーションの実行が中断される。ダウンタイムはそれほど大きくないが、それでも発生する。

●障害によるデータ損失（RAMに存在し、不揮発性ストレージに書き込まれていないデータのみ）。

●ランサムウェア対策なし。バックアップやディザスタリカバリのレプリケーションをHAと共に適用し、事業継続のアプローチを強化する必要がります。

●リソースを消費する。HAの運用には、非HA（または非FT）インフラよりも多くのハードウェア・リソースが必要です。

高可用性システムの実装方法

高可用性は、アプリケーション・レベルでもインフラ・レベルでも実装できる。アプリケーションによっては、MS SQL（Basic Always On 可用性グループ）のようにビルトイン HA を備えているものもありますが、最も一般的な HA は、クラスタリングと仮想化によってインフラストラクチャレベルで適用されます。複数のハードウェアサーバが 1 つのクラスタにまとめられ、その上でハイパーバイザ、アプリケー ション、およびサービスが実行されます。すべてのクラスタメンバーは、共有ストレージと共有設定データベースを持ちます。

クラスタ・メンバーに障害が発生した場合、その上で稼働しているサービス/アプリケーション/VM/コンテナは、健全な他のクラスタ・メンバーに切り替わります。Windows Server Failover Cluster、HA機能付きvSphere Cluster、Kubernetes Cluster、またはoVirt Clusterがその例です。共有ストレージは、外部SANまたはソフトウェア定義ストレージソリューション（StarWind vSANなど）によって提供されます。ハードウェア・ベンダは、ソフトウェア・スタック・バンドル付きのクラスタ・レディ・ノードを提供しているため、追加設定なしですぐに動作します。

フォールト・トレランス(FT)とは

フォールト・トレランスとは、データの損失やサービスの中断なしに、故障したハードウェアやOSから別の健全なハードウェアに、透過的かつ自動的にサービスやアプリケーションを切り替えるインフラの能力のことです。FTシステムでは、たとえ短時間であってもダウンタイムは発生しません。確かに、わずかなフェイルオーバー時間（ミリ秒/数秒）は発生するかもしれないが、この一種の障害は、FTサービスに依存しているユーザーや外部アプリケーションにはほとんど気づかれません。結局、RPOもRTOもゼロになります。

現実のシナリオでは短いソフトウェアのダウンタイムでさえ、ラインや最終製品の損傷や長い生産回復につながる可能性があります。FTシステムは、コンポーネントに障害が発生した場合、制御アプリケーションを別のハードウェアに透過的に切り替え、製品ラインは一切中断することなく稼働し続けることができます。

フォールトトレランスの利点

●ダウンタイムとRTOがゼロ（最悪の場合、RTOは存在するが、ユーザや外部アプリケーションにはまったく気づかない）。

●データ損失とRPOをゼロに。RAMや故障したハードウェア上にあったとしても、すべてのデータは利用可能なままです。

フォールトトレランスの欠点

●導入コストが高い。

●ランサムウェア対策がない。フォールト・トレランス自体では、サイバー犯罪から環境を保護できない。HAと同様に、バックアップやディザスタリカバリ・レプリケーションをFTと一緒に適用し、適切な事業継続アプローチを実施する必要がある。

●ネットワーク経由でRAMとCPU状態をリアルタイムにミラーリングするため、（HAに比べて）パフォーマンスが低下する。

●一般的な仮想化ITインフラ用途の完全なFT機能を備えた製品が限られている。

フォールト・トレランス・システムの実装方法

フォールト・トレランスは、HAと同じように、アプリケーション・レベルでもインフラ・レベルでも実装できます。アプリケーションベースのフォールトトレランスの実例として、Microsoft Active Directoryを挙げておいても差し支えないでしょう。ディレクトリはドメインコントローラー間で透過的にミラーリングされ、コントローラー1台が故障してもサービスは中断しないし、インフラにも影響しません。

仮想化環境ではHAと同様に機能するが、1つだけ重要な違いがあります。ハイパーバイザーが他のクラスタ・メンバー上にシャドウ・スタンバイVMを作成し、アクティブVMからシャドウVMにRAM、CPU、ストレージをレプリケートします。スタンドバイVMは、元の「アクティブ」VMが稼動していたハードウェアに障害が発生するとすぐに起動します。フォールト・トレラントなインフラ・ソリューションの好例は、FT機能を備えたvSphereです。

高可用性（HA) vs. フォールト・トレランスのまとめ

最後に：フォールト・トレランスは高いコストでサービス／アプリケーション機能を中断させないことを可能にし、ハイ・アベイラビリティは障害発生後の自動復旧を特別に高速化し、ダウンタイムを最小限に抑えることを可能にします。いままでの内容を踏まえると、ITインフラにはフォールト・トレランスが最適だと思われるかもしれません。というのも、これはコストの問題だけでなく、インフラがどれだけ複雑かという問題でもあるからだす。1年に1～2分のダウンタイムを許容できるビジネスであれば、高可用性が正しい選択であることは間違いありません。小さなダウンタイムでもビジネスに大きな影響を与えるのであれば、フォールト・トレランスの導入を真剣に検討すべき時です。この情報が役に立つことを願って終わりとします。

タグ: , , ,

Microsoft Azure Active Directoryのバックアップの重要性

投稿日: 2023年10月7日 クライム
Azure ディザスタ・リカバリ

今日のデジタル環境において、企業は重要なデータを保護し、ビジネスの継続性を確保するために、クラウドベースのサービスに大きく依存しています。Microsoft Azure Active Directory（Azure AD）は、Microsoftクラウド・サービスのIDおよびアクセス管理プラットフォームとして重要な役割を果たしています。このブログでは、組織のデジタル・アイデンティティを保護するために、Azure ADのバックアップがいかに重要である理由を探ります。

●ユーザIDとデータの保全： Azure ADは、Azureエコシステム内のユーザID、セキュリティグループ、アクセスポリシーの中央リポジトリです。Azure ADをバックアップすることで、アカウント設定、アクセス許可、およびグループメンバーシップを含む重要なユーザ情報を保護できます。そのため、偶発的な削除や悪意のある行為、システム障害が発生した場合でも、ユーザIDと関連データを迅速に復旧・復元できます。

●セキュリティ・リスクの軽減： 組織のデジタルIDを保護することは、今日の脅威の状況において極めて重要です。Azure ADをバックアップすることで、セキュリティ侵害、不正アクセス、またはデータ破損が発生した場合に、既知の良好な状態にロールバックできるため、セキュリティリスクを軽減できます。信頼性の高いバックアップソリューションにより、侵害されたアイデンティティを復元し、セキュリティインシデントの潜在的な影響を最小限に抑えることができます。

●ビジネス継続性の確保： Azure ADは、多くの組織のクラウドインフラのバックボーンであり、重要なリソース、アプリケーション、サービスへのアクセスを提供しています。Azure ADの障害やデータ損失は、事業運営や生産性に深刻な影響を与える可能性があります。Azure ADを定期的にバックアップすることで、ビジネスの継続性を確保できます。ユーザIDとアクセス制御を迅速に復元することで、ダウンタイムを最小限に抑え、重要なリソースへのシームレスなアクセスを維持します。

●コンプライアンスと監査の簡素化： 業界規制やデータ保護法の遵守は、さまざまな業種の組織にとって最優先事項です。Azure ADをバックアップすることで、ユーザID、グループメンバーシップ、アクセスポリシーの履歴を保持し、コンプライアンスへの取り組みを簡素化できます。正確な監査により、必要に応じて適切な管理とアクセス管理の証拠を提供できます。

●ディザスタリカバリの合理化： ハードウェアの故障から自然災害まで、災害は予期せず発生する可能性があります。堅牢なAzure ADバックアップ戦略により、このようなシナリオに備えることができます。定期的なバックアップにより、Azure ADのデータを迅速にリストアできるため、リカバリ時間を短縮し、プロセスを合理化できます。この機能は、不測の事態の影響を最小限に抑え、重要なサービスを迅速に復旧することを目指す組織にとって不可欠です。

Azure ADは、MicrosoftクラウドエコシステムにおけるセキュアなアクセスとID管理の基盤であるため、Azure ADのバックアップは、包括的なデータ保護戦略の不可欠な要素です。ユーザIDの保持、セキュリティリスクの軽減、事業継続性の確保、コンプライアンスの簡素化、ディザスタリカバリの合理化によって、Azure ADのバックアップは、組織のデジタルIDを保護し、重要なリソースへの中断のないアクセスを保証します。

信頼性の高いAzure ADバックアップソリューションに今すぐ導入計画し、デジタルIDが安全で、回復可能で、保護されているという安心感を得ることが重要です。

タグ: , , , ,

データ保管庫の種類

投稿日: 2023年9月24日 クライム
クラウド・仮想インフラ セキュリティ トラブル

データ保護に関連するイミュータブル(不変)・データ保管庫（IDV:immutable data vaults ）のコンセプトを考えるとき、最初に思い浮かぶのは「データは安全でセキュアなのか」ということです。通常、データは安全かつセキュアなのだろうか？私たちは安全でセキュアなデータのコピーを持つことがいかに重要であるかを知っています。しかし、一般的に後回しにされがちなのは、イミュータブルデータをどのように復元するか、そして復元にかかる労力と時間です。安全なデータ保管と信頼性の高い高速リカバリの両方を保証する保管庫ソリューションは、最良の選択肢です。

イミュータブルデータ保管庫は、一度保管されたデータの改ざん、削除、不正な変更を防止する方法でデータを保管するように設計されています。これは、金融やヘルスケアなど、データ保持やコンプライアンス要件が厳しい業界では特に重要です。データ保護の領域では、いくつかのタイプのイミュータブルデータ保管庫が使用されています。

1.ストレージ・アレイ・ベース： Write Once, Read Many (WORM)ストレージ・システムは、最も一般的なタイプのイミュータブルデータ保管庫です。アレイベースのイミュータブル性オプションを見ると、通常2つの業界標準のカテゴリーがあります。 スーパーアドミニストレータ以外にはコピーの変更や削除ができない「ガバナンスモード」と、スーパーアドミニストレータやサポートを含む誰によってもコピーの変更や削除ができない、より厳格な「コンプライアンスモード」です。

2. クラウドストレージベース： 一部のクラウド・ストレージ・プロバイダーは、WORM機能をサービスとして提供しています。これらの機能のほとんどは、”オブジェクト・ロック “を介してクラウド・オブジェクト・ストレージ・レベルで有効化される。AWSやAzureなど、多くのクラウド・プロバイダーでこれらの機能を見つけることができます。

3. 分散型台帳技術（DLT：Distributed Ledger Technology）保管庫： DLTはブロックチェーンを含むより広い用語であるが、他の形態の分散型台帳も包含することができます。DLTは、データを複数のノードに分散させ、改ざんを困難にするイミュータブルのデータ保管庫を作成するために使用できます。最も一般的なDLTの1つがHyperledger FabricですHyperledger Fabricは、オープンで実績のあるエンタープライズ・グレードの分散台帳プラットフォームです。高度なプライバシー管理機能を備えているため、共有対象のデータのみが、「許可されている」（既知の） ネットワーク参加者間で共有されます。

4. イミュータブルファイルシステム： オペレーティングシステムやファイルシステムの中には、一度書き込まれたファイルの修正や削除を極めて困難にする機能を提供するものがあります。これを利用して、システムレベルでイミュータブルのデータ保管庫を作ることができます。OSレベルでは、イミュータブルを実現する方法がいくつかあり、BottleRocket、Talos Linux、Flatcarなど、最高レベルのセキュリティを提供できるイミュータブルOSもある。

これらのタイプのデータ保管庫は素晴らしいものですが、分離されたリカバリ環境（IRE：isolated recovery environment ）と組み合わせるとさらに有益です。IREは、イミュータブルのデータコピーからデータを検証し復旧するためのリソースを備えた、専用の安全な復旧環境です。イミュータブル・データ・アーキテクチャーとは、一度書き込まれたデータは決して変更できないため、ランサムウェアによって暗号化されることはないということです。イミュータブル・ストレージを備えたIREは、従来のデータ保護ツールに取って代わるものではなく、重要なデータに対する三次的なソリューションとして位置づけられています。Gartnerは、この2種類の技術を組み合わせることの価値を認め、「イミュータブルデータ保管庫（IDV）を備えた分離リカバリ環境（IRE）は、インサイダーの脅威、ランサムウェア、その他の形態のハッキングに対して最高レベルのセキュリティとリカバリを提供する」と述べています。

データ保管庫のセキュリティの次のステップとして、IDVとIREの両方を組み合わせて迅速なエアギャップ復旧を実現することで、データの保護と復旧の両方を確保することが望まれます。

クライムのランサムウェア・ソリューション概要をご覧ください。

タグ: , , ,

中断のないIT運用とは： 高可用性(ハイ・アベイラビリティ)とディザスタ・リカバリを分かりやすく説明

投稿日: 2023年9月18日 クライム
ディザスタ・リカバリ

IT運用を常にオンラインに保つという困難な状況において、高可用性（ディザスタ・リカバリ: HA：High Availability）とディザスタリカバリ（DR:Disaster Recovery）という対照的な方法論を理解することは最も重要です。ここでは、アプリケーション回復力のダイナミック・デュオである HA と DR について検証していきます。高可用性とは何か、その利点と欠点、そして高可用性とDRの両方を採用すべき理由について説明します。

高可用性(HA)とは：

高可用性とは、アプリケーションのサービスへのアクセスを要求しているクライアントにサービスを提供し続ける能力のことです。これらのサービスは、仮想マシン、クラウドインスタンス、コンテナ、またはこれらの技術を組み合わせたノード上でホストされます。アプリケーションをホストするために使用されるHAクラスタリング構成には、アクティブ-パッシブとアクティブ-アクティブの2種類がある。

アクティブ・パッシブ：

アクティブ・パッシブ・クラスターで実行されるアプリケーションは、2つ以上のノードで構成され、最初のノードがアクティブな状態でクライアントをホストし、アプリケーションへの接続を提供し、他のノードはパッシブまたは「スタンバイ」状態になります。スタンバイサーバーは、プライマリ（アクティブ）サーバーが切断されたり、クライアントのリクエストに対応できなくなったりした場合にフェイルオーバーできる、アプリケーション環境のすぐに使えるコピーとして機能します。

プライマリ・サーバに障害が発生した場合、サービスを実行するプロセスはスタンバイ・クラスタに移動します。これには時間がかかり、クライアントへのサービスが中断する危険性があります。

アクティブ・アクティブ:

アプリケーションのダウンタイムが耐えられない場合は、アクティブ・アクティブ・クラスタを導入することで、より高いレベルのアプリケーション可用性を実現できます。アクティブ・アクティブ・クラスタ・アーキテクチャは、2つ以上のノードで同じサービスを同時にアクティブに実行します。そうすることで、アプリケーションはロードバランシングによって複数のクライアントのアクセスに対応することができます。ロードバランシングとは、アプリケーションの過負荷を防ぐために、クラスタ内のすべてのノードにワークロードを分散させることです。すべてのクライアントに対してより多くのノードがサービスを実行するため、アプリケーションの応答時間は劇的に改善される。このアーキテクチャーは、アプリケーションが常にオンラインであることを保証できる一方で、コストがかかる。

まとめると、HAアーキテクチャの利点は以下の通りです：

●クラスタ内の単一障害点の排除
●アプリケーションのワークロードをコンピュートリソース全体でバランスさせ、需要の増加に対応できるようにクラスタを拡張する。

しかし、欠点もあります：

●時間がかかる- 一貫したアプリケーションのアップタイムを維持するには、複数のノードを導入する必要がある。
●パフォーマンスの問題-専用リソースを必要とするアプリケーションでは、共有ストレージはうまく拡張できない。
●オーケストレーションされたリカバリーがない-アプリケーションが破損した状態でオンラインに戻る可能性がある（最悪の場合、分散サービス拒否（DDoS）攻撃の要求に応えようとするためにスケーリングされる）。

ディザスタリカバリ(DR)はデータ保護戦略の重要な要素

DRは、アプリケーションのすべてのコンポーネントをローカルまたはリモート・サイトに複製することで、アプリケーションの可用性とデータのアップタイムを保証します。フェイルオーバーは、システムレベルとネットワークレベルの冗長性を提供することで、DR計画の一部となります。フェイルオーバーにより、災害時や定期メンテナンス時でも、ダウンタイムをほとんど発生させることなく業務を継続することができます。

強力なDRソリューションには以下が含まれます：

●継続的なデータ保護-わずか数秒のデータ損失でサイト全体、アプリケーション、ファイルを復旧可能
●自動化とオーケストレーション – 複雑さを最小限に抑え、手動タスクを最小限に抑えることで、フェイルオーバー操作を可能な限りシンプルにします。
●アプリケーションの一貫性 – まったく同じ時点からアプリケーション全体が一緒にフェイルオーバーされるため、リカバリーのスピードが向上し、リカバリーの複雑さが軽減されます。
●影響を与えないテスト – DRテストのフェイルオーバーをいつでも実行できるようにすることで、システムのテストが完全に行われ、SLAが満たされていることを確認します。
●可視性と制御 – データ保護ソリューションの内部で発生していることを完全に理解し、確認できるようにし、リアルタイムのデータと過去のレポート機能によって貴重な洞察を得ることができます。

アプリケーションを HA クラスタとしてデプロイするだけでなく、DR を利用することで、バージョニングの問題やアプリケーションの脆弱性の悪用による計画外の停止に対する保護がさらに強化されます。DRソリューションを活用すると、HAアプリケーションは、通常、障害が発生する数秒から数分前に、運用上安定した状態でオンラインに復帰します。アプリケーションとそのサービスが再適用されると、復旧したサイトでHAを有効にし、クライアントのリクエストに対応し続けることができる。つまり、DRを使用してフェイルオーバー機能を追加することで、潜在的なアプリケーションの中断に対するデータ保護のレイヤーが追加されます。

結論として、強力なデータ保護戦略には、StarWindのようなHAとZertoのようなDRを並行して実行することが含まれます。データ保護は、重要な情報を破損、危殆化、または損失から保護するものであり、データ復旧は、紛失、誤って削除、破損、またはアクセス不能になったデータを復元するプロセスである。戦略は、最善のものであるだけでなく、相互運用可能で、両方のプロセスを補完するものである必要があります。

タグ: , , , , ,

RAID5とは？| RAID 5アレイと構成

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

 

RAID 5は、ディスクのストライピングとパリティの両方を使用するハードディスクドライブのデータバックアップ技術です。RAIDのレベルの1つ： RAIDとは、Redundant Array of Independent Disksの略で、元々はInexpensive Disksの略です。RAIDは1980年代に開発され、複数のバージョンがありますが、RAID 5はその一つに過ぎませ。IBMは1980年代からRAID 5の特許を持っています。

RAID 5テクノロジー

ディスクのストライピング

ディスクのストライピングは、RAIDの初期バージョンであるRAID 0で初めて導入されました。これはアレイ内の全データを複数のディスクに分散します。しかし、ディスクのストライピングは、1つのディスクが故障するとそのディスク上のデータが失われ、失われたファイルを回復する方法がないため、信頼性の低いバックアップ技術であることがすぐに判明しました。

ディスク・ミラーリングは、技術の専門家ならRAIDを連想するでしょうが、ディスクの冗長性を作り出す一般的な技術です。データは1つのディスクから、それをミラーリングするもう1つのディスクに完全にコピーされます。しかし、RAID 5はディスク・ミラーリングを使用せず、ディスク・ストライピングとパリティと呼ばれるデータ・チェック技術を組み合わせています。

パリティ

エラーによってファイルのビットが失われる可能性があるため、パリティはデータが正しく転送されることを保証します。パリティは、チェックサムを通じてビットチェックを行い、データの安全性を管理します。ディスクのストライピングは信頼性の高いバックアップ・システムを提供しませんが、パリティはデータが失われたときにそれを判断するように設計されています。

パリティを使用するディスク・ドライブは、他のドライブからのすべての情報に基づいて、失われたデータを再構築することができます。パリティは、失われたデータを再構築するために、他のディスクに残っている情報と自分の持っている情報を使って、XOR演算によって数学的に行います。

パリティを使用するアレイには、通常、パリティデータ専用のドライブ容量が必要です。しかし、RAID 5のパリティは、1つのディスクにすべて保存するRAID 4とは異なり、各ドライブに分散されます。これにより、セキュリティが強化されます（ドライブが故障しても、すべてのパリティデータが失われるわけではありません）。また、ディスクドライブに関する一般的な注意点として、RAID構成をフォーマットするとそのスペースの一部が使用されるため、ディスクで使用可能な正確な容量が広告に記載されている容量と異なる場合があります。

RAID 5の利点とは？

RAID 5は、RAIDの最も一般的な構成の1つです。2つのディスク技術を組み合わせることで、データ損失を最小限に抑え、読み取りパフォーマンスを向上させます。RAID 5はディスクのストライピングを使用するため、他のRAIDよりも高速な読み取り速度を実現します。データはドライブに分散されるため、ドライブは同時に読み取ることができます。ディスクのストライピングはそれだけでは信頼できるバックアップ技術ではありませんが、RAID 5はパリティも使用してデータの正確性をチェックし、必要に応じてデータを置き換えます。

RAID 5は3台のディスクドライブしか必要としないため、小規模なディスクアレイの冗長ソリューションとして適しています。また、より安価な冗長バックアップソリューションの一つでもあります。

RAID 5のデメリットは？

RAID 5は小規模なアレイには適していますが、大容量ディスクやサーバには適していません。特に大容量ディスクは書き込みに時間がかかります。あるディスクに障害が発生し、アレイがRAIDを使用してデータを再構築する場合、書き換えプロセスが終了する前に別の問題が発生する可能性があります。RAID 5は複数のディスク障害に耐えられるようには設計されていないため、2つの障害でアレイ全体がダウンする可能性があります。

ディスクの故障はHDDに起こりうることであり、RAID 5は合計1つのディスク故障しか許容しないため、大規模なアレイに適したソリューションではないし、ディスクに保存されたファイルの唯一のバックアップソリューションであるべきでもありません。多くのデータストレージの専門家は、ハードドライブはディスク故障の影響を受けやすく、複数のディスク故障がデータ損失の原因となるため、RAID 5はもはやハードドライブのバックアップソリューションとしては適していないと考える人もいます。

SSD向けRAID 5

RAID 5はソリッドステートドライブ（SSD)にも使用できます。ソリッドステートドライブは不揮発性メモリ記憶装置で、ハードドライブよりもはるかに高速です。SSDはHDDよりも故障しにくく、読み込み速度も速いので、リビルド処理も速くなります。

データの再構築にパリティを使用する場合、SSDは2回目の故障の影響を受けやすいです。一度に複数の回復不能な読み取りエラー（URE）が発生する可能性は低いが、HDDはリビルド中に複数のUREが発生する可能性が高いです。

唯一の潜在的な問題は、SSDが最終的に故障した場合、同じ寿命であれば、アレイ内の他のSSDも同じ時期に故障する可能性が高いということです。そのため、SSDにRAID 5を採用する場合は、まったく同じ年式ではないドライブを使用することを検討したほうがよいでしょう。異なるドライブを使用すると、互換性の問題など他の問題が発生する可能性がありますが、ドライブが同時に故障すると、データ全体が失われる可能性があります。

編集後記：RAID ６

RAID 6はRAID 5 とほぼ同じ構成で、各ディスクに複数のパリティブロックを使用するデュアル分散パリティのブロックレベルストライピングを使用します。

タグ: , , ,

ハイブリッド・クラウド・インフラの利点、欠点、導入に関する注意点

投稿日: 2023年8月22日 クライム
クラウド・仮想インフラ

ハイブリッド・クラウド・インフラは、オンプレミスのITコンピューティングとクラウドベースのリソースを組み合わせたもので、企業がITの目標を達成し、ビジネス・ワークフローを促進するのに大いに役立ちます。プライベート・クラウドとパブリック・クラウドの両方の利点を組み合わせることで、ハイブリッド・クラウドは両方の長所を提供します。

ハイブリッド・クラウドのソリューションにより、企業は特定のビジネス・ニーズに基づいて、よりダイナミックなセットアップを行うことができます。そのため、パブリック・クラウド環境とプライベート・クラウド環境の間でワークロードを移行し、管理することが可能になります。コスト削減、拡張性、リスクの最小化など、ハイブリッド・クラウド・インフラがもたらすメリットにより、企業は急速にハイブリッド・クラウド・インフラを採用しています。

さらに、ハイブリッド・クラウドの採用は、多くの企業のライフサイクルにおいて自然な進化となっています。オンプレミスのインフラでは受信データやトラフィックに対応できなくなるため、パブリック・クラウド環境に体系的に移行する必要があります。そのため、パブリック・クラウドの機能を活用しながらオンプレミスのサービスを使い続けることができるハイブリッド・クラウド環境が必要になります。

ハイブリッド・クラウドの仕組み

ハイブリッド・クラウド・アーキテクチャの考え方は、企業のオンプレミス・データセンターの一部をプライベート・クラウド・インフラに変換し、それをパブリック・クラウド・インフラに接続することに重点を置いています。これにより、アプリとデータが2つの環境（パブリック・クラウドとプライベート・クラウド）間をシームレスに行き来できるようになります。更に、企業はより高い柔軟性とより多くのデプロイメント・オプションで、より迅速にスケーリングできるようになります。

例えば、ウェブベースの電子メールなど、量が多くセキュリティが低いニーズにはパブリック・クラウドを使用し、財務報告など機密性が高くビジネスクリティカルな業務にはプライベート・クラウド（またはその他のオンプレミス・インフラストラクチャ）を使用するといったことです。

ハイブリッド・クラウドが効果的に機能するためには、パブリックとプライベートの環境間で高レベルの相互運用性とオーケストレーションが存在する必要があります。これは、LAN、WAN、VPN、およびクラウド管理プラットフォームによって実現され、統一されたインフラストラクチャを担当し、管理者が両方の環境にわたって管理、統治、およびオーケストレーションを行うことができます。

他のクラウド・コンピューティング・インフラと同様に、ハイブリッド・クラウド・プラットフォームはコンテナ化、仮想化、ストレージ技術を使用してリソースを集約することです。これらのリソースは、専用の管理ソフトウェアを使用して、異なる環境間で割り当ておよび共有することができます。

ハイブリッド・クラウド・インフラの利点

プライベート・クラウドとパブリック・クラウドのインフラには、それぞれ欠点があります。ハイブリッド・クラウド・アーキテクチャがこれらの欠点を軽減し、両方の環境の長所を提供するのはそのためです。ハイブリッド・クラウド・インフラの利点を見てみよう：

効果的なアプリ・ガバナンス

ハイブリッド・クラウドのアプローチでは、アプリの設置場所とハイブリッド・コンピューティングの実行場所を選択できます。これにより、特に規制対象のアプリについては、より高いレベルのプライバシとコンプライアンスが保証されます。

パフォーマンスの向上と待ち時間の短縮

ハイブリッド・クラウド・モデルでは、ワークロードを最適な場所に配置できます。機密性が低く、パフォーマンスが高いアプリケーションはパブリッククラウドに配置し、機密性が高く、ミッションクリティカルなアプリケーションはプライベートクラウドで保護することができます。

ROI（投資効率）の向上

既存のプライベートクラウドアーキテクチャにパブリッククラウドインフラストラクチャを採用することで、データセンターの経費を増やすことなく、クラウドコンピューティングのキャパシティを拡張することが可能になります。

柔軟な運用

ハイブリッド・クラウド・コンピューティングでは、企業は特定のニーズに最適な環境で柔軟に運用できます。そのため、ビジネスデータのオフサイト・バックアップが必要な企業は、パブリック・クラウド・サービスを利用するだけで、複数のサイトを用意する必要がなくなります。

ビジネスの継続性

災害が発生した場合でも、ハイブリッド・クラウド上にデータを保存しておけば、安全かつセキュアな場所にデータをバックアップし、保護することができます。これにより、悪条件下でもビジネスの継続性を確保できます。

リソースの最適化

ハイブリッド・アプローチでは、リソースをより効果的に活用できます。パブリック・クラウドのリソースは、変動するキャパシティ・ニーズや余剰キャパシティ・ニーズに対応するために使用することができ、プライベート・クラウドのリソースは、需要が減少したときに縮小することができます。

コンプライアンスとセキュリティの向上

パブリック・クラウドのセキュリティは大幅に向上していますが、プライベート・クラウドのセキュリティは依然として高いレベルにあります。ハイブリッド・クラウドでは、最も機密性の高いデータをプライベート・クラウドに保管することができます。

ハイブリッド・クラウドの欠点

ここまで、ハイブリッド・クラウド・インフラを採用する主なメリットをいくつか見てきた。次に、企業がハイブリッド・クラウドを利用する際に遭遇する可能性のあるいくつかの制限について考えてみます：

ハイブリッド・クラウド・インフラは、プライベート・クラウドとパブリック・クラウドのアーキテクチャを組み合わせたものであるため、両者の長所と短所が内在しています。
パブリック・クラウドと同様、クラウド・インフラはサード・パーティが所有するため、企業はクラウド・インフラをあまり上手にコントロールできません。さらに、プライベート・クラウドとパブリック・クラウドを組み合わせることで、インフラの複雑さが増します。つまり、組織のビジネス・ニーズの変化に応じて、この2つの異なるタイプのクラウドを維持・管理するには、より多くの時間とトレーニングを受けた人材が必要になるということになります。

パブリック・クラウドのインフラをコントロールできないため、機密データの保護や規制の遵守が難しくなります。そのため、データの保護と規制の遵守をクラウド・サービス・プロバイダに頼ることになります。しかし、セキュリティ侵害が発生しないようにするのはクラウド・サービス・プロバイダーの仕事であるにもかかわらず、顧客がセキュリティ侵害の責任を負うことになります。

ハイブリッド・クラウドの使用例

ハイブリッド・クラウド・インフラは、パブリック・クラウドのスケーラビリティと柔軟性の利点と、オンプレミス・アプローチのセキュリティの利点を求める企業に適しています。以下にユースケースをいくつか紹介する：

規制コンプライアンスの維持

医療や金融などの業界で事業を展開することは、特に厳しい規制要件のために非常に困難な場合があります。しかし、ハイブリッド・クラウドを利用することで、これらの要件を遵守することができます。例えば、一部のヘルスケア・アプリケーションは、セキュリティ上の理由からプライベート・クラウド上でのみ実行する必要があります。ハイブリッド・クラウドを利用すれば、パブリック・クラウドを他のプロセスに利用しながら、このようなことも可能になります。

クラウド間の移行

ハイブリッド・クラウドのインフラを使えば、企業はクラウド・ベンダー間で簡単に移行できます。特定のベンダーに縛られることなく、企業の新たなニーズに対応する優れたソリューションが他のベンダーから提供されれば、簡単に移行できます。

ダイナミックなワークロードへの適応

パブリック・クラウドは拡張性があり、動的なワークロードに適しています。また、揮発性の低いワークロードや機密性の高いワークロードには、オンプレミスのデータセンターを使用することが適切です。つまり、これら2つの機能を同時に実現する唯一の方法はハイブリッド・クラウド・インフラを利用することです。

オフサイト・バックアップ

ハイブリッド・クラウドのアプローチを利用する企業は、追加のインフラに投資することなく、パブリック・クラウドをオンプレミスの重要なデータをバックアップするサイトとして利用できます。さらに、災害時にはこのデータを瞬時に取り出すことができます。これにより、シームレスな事業継続が可能になります。

ハイブリッド・クラウド・インフラを導入するには？

ハイブリッド・クラウド・インフラの導入は、多くの人が考えているほど複雑ではありません。しかし、ハイブリッド・クラウドを効果的に導入するためには、自社のビジネス要件に基づいてハイブリッド・クラウド戦略を定義する必要があります。主な手順は以下の通りです：

1.ビジネス要件を特定する： パブリック・クラウド・インフラで実行するワークロードと、プライベート・クラウドに移行するワークロードを決定します。ワークロード環境は、ハイブリッド・クラウド戦略の成功に極めて重要な役割を果たします。ワークロードを適切な環境に置くことで、より効果的で効率的なワークロードを実現できる一方、間違った環境に置くと導入が複雑になる可能性があります。

2.適切なプロバイダーとテクノロジーを選択する： クラウドプロバイダーの選択は、ビジネス要件を特定した次の論理的なステップです。プロバイダーが、ビジネスの当面のニーズと将来のニーズに対応できるオプションを持っていることを確認します。また、セキュアで信頼性の高い方法で環境を接続するための一般的なネットワーク・トポロジーとテクノロジーを特定する必要があります。

3.セキュリティとコンプライアンス対策の実施: セキュリティとコンプライアンスの問題は、企業がパブリック・クラウドを導入する際に直面する最重要課題の1つです。ハイブリッド環境はプライベート・クラウドとパブリック・クラウドの両方のインフラで構成されるため、データの保存時および両環境間でのデータ転送時にデータが保護されていることを確認する必要があります。さらに、関連する規制に準拠しているかどうかも常にチェックします。

4.ガバナンスと管理システムの確立: 管理者はハイブリッド・クラウド環境を効果的に管理するシステムを導入する必要があります。パフォーマンス監視、コスト管理、パブリック・クラウドとプライベート・クラウド間のアプリとデータの相互運用性の確保に大いに役立ちます。

結論

ビジネスの継続性と拡張性が成功に欠かせないこの時代において、ハイブリッド・クラウド戦略の採用は最良の選択肢です。ハイブリッド・クラウドは、柔軟性、拡張性、セキュリティ、コスト削減など、多くの面で両者の長所を兼ね備えています。しかし、ハイブリッド・クラウド・インフラは、これらのメリットを受け継ぐと同時に、完璧なものではありません。そのため、このアーキテクチャを導入する前に、自社のビジネス要件に合っていることを確認する必要があります。株式会社クライムではユーザのハイブリッド・クラウド導入・移行を手助けする多くのソリューションを提供しています。

タグ: ,

仮想化ていったい何なのでしょうか？その詳細は？

投稿日: 2023年8月18日 クライム
クラウド・仮想インフラ

仮想化の種類

仮想化にはさまざまな種類があり、それぞれに利点と目的があります。ここでは、最も一般的な仮想化の種類をいくつか紹介します：

サーバ仮想化：サーバの仮想化により、ユーザは物理サービスをより小さな仮想サーバに分割し、サーバのリソースを最大限に活用することができます。これにより、ユーザはサーバ・リソースの複雑な詳細を管理する必要がなくなり、リソースの共有、利用、スケーラビリティが向上します。各仮想サーバは、物理マシン上の他の仮想サーバとは独立して、独自のオペレーティング・システムとアプリケーションを実行します。VMwareのvSphere、マイクロソフトのHyper-Vがこれに含まれます。

ネットワーク仮想化： ネットワーク仮想化では、利用可能な帯域幅を独立したチャネルに分割し、それぞれを特定のサーバやデバイスにリアルタイムで割り当てることができます。同じ物理ネットワーク上に複数のネットワークを存在させることができるため、ネットワークの複雑さを軽減し、スピード、セキュリティ、柔軟性を向上させることができます。

ストレージ仮想化： これは仮想化の一種で、複数のネットワーク・ストレージ・リソースがプールされ、中央コンソールで管理される単一のストレージ・デバイスのように見えます。ストレージ仮想化は、データストレージの効率と速度の向上に大きく貢献する。ストレージ・エリア・ネットワーク（SAN）でよく使用されます。

アプリケーションの仮想化： これは、ハードウェアやオペレーティング・システムからアプリケーション・レイヤーを分離するプロセスです。これにより、アプリケーションは物理マシンのオペレーティング・システムに依存せずに実行できるようになるります。これにより、ユーザは2台のコンピューターを用意することなく、Linux OS上でWindowsアプリを実行したり、逆にLinux OS上でWindowsアプリを実行したりすることができます。DockerやKubernetesがこれらに含まれます。

デスクトップ仮想化： VDIなどのデスクトップ仮想化により、管理者はホストサーバ、集中管理サーバ、またはリモートサーバ上にシミュレートされたデスクトップ環境を展開することができます。そのため、ユーザはどのワークステーションやデバイスからでもデスクトップにアクセスできます。さらに、管理者はすべての仮想デスクトップでアップデート、セキュリティ・チェック、一括設定を簡単に実行できます。

データの仮想化： 現代の企業はデータを複数の場所に保存しているため、アプリが場所、形式、ソースに関係なくすべてのデータにアクセスできるようにする必要があります。それがデータ仮想化の目的です。異なるソースからデータを収集し、1つの場所で閲覧できるようにすることで、ユーザにデータへのシングル・アクセス・ポイントを提供します。

仮想化のメリット

仮想化は、あらゆる組織に多くのメリットをもたらします。これらの利点のいくつかを見てみましょう：

効率的なリソース使用
仮想化がない場合、各アプリ・サーバには専用の物理CPUが必要でした。そのためITスタッフは、実行するアプリごとに個別のサーバを購入し、構成する必要がありました。これでは物理サーバが十分に使用されず、リソース効率が悪かった。しかし、仮想化により、1つの物理デスクトップ上で複数のアプリ（それぞれが仮想マシン）を実行できるようになった。こうすることで、物理コンピュータのリソースと容量を効率的に利用できる。また、新しいハードウェアを購入するコストを削減し、データセンターのスペースを空け、電力を節約することができる。

より簡単な管理
物理デスクトップをVMに置き換えることで、IT管理者はソフトウェアで記述されたポリシーを簡単に管理・使用できるようになります。自動化されたITサービス管理ワークフローの作成がシームレスになります。仮想化により、物理的なコンピュータやサーバを手動で構成したり設定したりする、面倒で時間のかかる、ミスの起こりやすいプロセスが不要になります。

ダウンタイムの最小化
自然災害、サイバー攻撃、OSやアプリのクラッシュは、物理的なサーバやマシンでは大きなダウンタイムを引き起こし、ユーザの生産性を低下させます。しかし、仮想化により、このような不測の事態からの復旧がシームレスになります。多くのボトルネックを抱えることなく、ビジネスの継続性を確保します。

なぜ仮想化が重要なのか？
仮想化を利用することで、ユーザはハードウェア・リソースを柔軟に利用できるようになります。物理サーバにはそれなりの利点があるとはいえ、メンテナンスが必要で、ストレージ・スペースを取り、多くの電力を消費します。さらに、サーバの近くにいる人しかアクセスできません。仮想化によって、これらの制限はすべて取り除かれる。ハードウェアの物理的な機能はソフトウェアに変換されます。そのため、ユーザはハードウェア・インフラをウェブ上のアプリのように使用、保守、管理することが可能になる。

例えば、ある企業では、ビジネスメールを安全に保存し、クライアントサイドや社内のビジネスアプリを実行する必要があるワークフローがあるとします。これら3つの機能は、構成要件が異なるため、すべて異なるサーバを必要となります。さらに、電子メールアプリはWindows OSとより優れたストレージを必要とし、クライアントサイドアプリはLinux上でのみ動作し、リソース集約的です。この企業がワークフローを成功させるためには、3つの異なる物理サーバをセットアップする必要があります。この場合、リソースが十分に使われていないにもかかわらず、初期費用がかさみ、個々のサーバのメンテナンスやアップグレードが常に必要になります。

しかし、仮想化を使えば、1台の物理マシンから3つの異なる機能の仮想サーバを作成することができます。それぞれの仮想サーバは、独自のオペレーティング・システムとアプリケーションを実行できる。また、各仮想サーバとその機能の実行に必要なリソースは、物理マシンに応じて割り当てられます。これにより、柔軟性とスケーラビリティが向上し、ハードウェアや関連費用の削減が可能になります。

StarWindによる仮想化

StarWind社は、仮想化分野において、フルスタックのデータセンター・インフラを構築するために必要なすべての「ビルディング・ブロック」をワンストップで提供する仮想化ショップです。

StarWind社は、高可用性とデータセンタ仮想化のためのソフトウェア製品を提供しています。例えば、StarWind Virtual SAN（vSAN）は、ハイパーバイザー・サーバ間で内部ハードディスクとフラッシュをミラーリングし、物理的な共有ストレージ（SAN）を不要にするソリューションです。このソフトウェアを使用することで、企業は完全に冗長化されたフォールトトレラントなインフラを手に入れ、中断のないアップタイムを実現できます。

仮想化 vs クラウド vs コンテナ化

クラウド・コンピューティングは、インターネット上で共有コンピューティング・リソースを従量課金で提供するサービスです。そのため、企業は物理的なデータセンターを購入、所有、維持する必要がありません。ビジネスのニーズに応じて、クラウドからコンピューティング・リソースを得ることができる。

一方、クラウド・コンピューティングが存在するのは仮想化のおかげです。仮想化によって、クラウド・プロバイダは独自のデータセンタを構築し、維持することができます。クラウド・プロバイダは、ホスト・マシンのハードウェア・リソースに依存する複数の仮想環境を生成することができます。企業は現在、APIを通じてこれらのクラウドリソースにアクセスすることができます。

コンテナ化は仮想化と似ているが、規模ははるかに小さいものです。完全なマシン仮想化の代わりに、コンテナ化はアプリを独自のOSを持つコンテナにカプセル化します。つまり、アプリのコードは何も手を加えることなく、どんな仮想環境でも物理環境でも実行できます。そのため、開発者はアプリのコードを設定ファイルや関連ライブラリ、その他実行に必要な依存関係とともにパッケージ化します。

仮想化の限界

仮想化環境の導入は、物理的な機器を購入するよりも初期費用が少なくて済みます。しかし、それでも仮想化の様々な初期コストを考慮することは不可欠です。仮想化を実現するために必要な投資は、企業の予算を大きく圧迫します。既存のITインフラにデータがない場合は、さらにコストがかかります。

ソフトウェア・ライセンスも、仮想化環境の導入を検討する際に越えなければならないボトルネックの1つです。企業は、仮想化環境でのソフトウェアの使用に関して、ベンダーがどのようなポリシーを持っているかを明確に理解する必要があります。

仮想化への切り替えには時間がかかり、従業員は仮想化環境での作業方法を習得する時間が必要です。また、物理環境で使用していたすべての業務アプリが仮想空間でうまく動作するとは限りません。そのため、これらの課題に直面することを覚悟し、切り替える前に常に代替アプリを探しておく必要があります。

結論

仮想化は、1台の物理マシン上で複数のシステムやアプリを同時に実行できるようにすることで、企業がコンピュータ・リソースを使用する方法を形成しています。企業は、サーバ、ネットワーク、デスクトップの仮想化など、さまざまな形で効率性、柔軟性、拡張性、コスト効率の恩恵を受けています。間違いなく、ITリソースを管理する方法として、仮想化は徐々に不可欠なものになりつつあります。

仮想化は、クラウド・コンピューティングやコンテナ化の進歩のためのビルディング・ブロックとなっています。仮想化のパワーを活用する企業は、ITの俊敏性と応答性を向上させ、イノベーションと成長の面で他社をリードすることができます。

タグ: ,

Microsoft 365パーミッションの課題と改善方法は

投稿日: 2023年8月16日 クライム
クラウド・仮想インフラ セキュリティ

Microsoft 365 SharePoint、OneDrive、Teams、グループは異なるコンソールで管理され、しばしば異なる管理者、場合によってはパワーユーザによってさえ管理されることもあります。 これらの権限とレポートに対する一元的な可視性がなければ、企業はガバナンスの問題を抱えたまま、企業データを誤った社内外のチームに公開してしまうかもしれません。適切なガバナンスの必要性には、レビュー、監査、修復ができることが不可欠です。ここでは、これらの課題をレビューし、是正する方法を考えてみます。

Microsoft 365の権限と課題

Microsoft 365とそのビルトイン機能は使い方がシンプルで、権限さえあれば誰でもすぐに使い始めることができる。 使いやすさは大きな利点であるが、コンテンツの乱立やパーミッション周りのコントロール不足を引き起こす可能性があります。デフォルトでは、ほとんどのユーザがSharePointのサイトや自分のOneDrive、アクセスできるTeamsのサイトにコンテンツを追加できるように、パーミッションは十分高く設定されています。適切なガバナンスがないままMicrosoft 365ツールを導入している組織はいくつもあります。

修復

これらの修復プロジェクトは一般的に複雑だが、どれだけのコンテンツが扱われているか、SharePoint、Teams、OneDrive内に作成されたフォルダ、サイト、ドキュメントの数によって複雑さが異なります。 多くの場合、PowerShellスクリプトの作成と.csvレベルのファイルレビューが、データと権限のレビューのための最良の選択肢でした。 ケースバイケースで改善策を考えます。

SharePoint: サイト管理者がグローバル権限を持っている場合、各サイトを手動でレビューするか、PowerShellスクリプトでcsvにエクスポートします。 どちらも時間がかかり、サイトやサブサイトの数によっては大規模なプロジェクトになる可能性があります。

注：また、サイト管理者のパーミッションが誰かによって削除され、可視性が失われるという単発のシナリオもあり得ます。

Teams： Teamsでのサイトのセットアップは非常にシンプルで、ガバナンス・ポリシーも必要です。 Teamsはドキュメント、ミーティング、チャットなどに使用できるため、パーミッションが重要になります。また、適切なガバナンスがなければ、管理者は重要なものが見られてはいけない人に見られていないかどうか把握するのに走り回ることになります。

OneDrive： ユーザのOneDriveの権限は、初期状態では各ユーザのOneDriveとテナント管理者に制限されているため、もう少し管理されています。 しかし、個々のユーザは自分のOneDriveの権限でドキュメントに権限を追加することができ、テナント管理者も同様です。そのため、これらをレポートできることは、適切に理解し、監査するために非常に重要です。

まとめ

SharePoint、OneDrive、Teamsを通してMicrosoft 365の権限を理解することは、企業データを理解し保護する上で非常に重要です。 時間をかけてMicrosoft 365ワークロードを監査し、この作業をシンプルかつ効率的に行えるようにするようなソリューションを考えることも選択肢です。

追記：Microsoft Office 365対応のバックアップ・ツール

●Veeam Backup for Microsoft Office 365
●Climb Cloud Backup for Microsoft 365　

タグ:

クラウドセキュリティ戦略の見直しの必要性

投稿日: 2023年7月11日 クライム
AWS Azure クラウド・仮想インフラ セキュリティ

デジタル時代において、データは世界中の企業にとって最も価値のある資産の1つとなっています。Amazon Web Services (AWS)やMicrosoft Azureなどのクラウドプラットフォームへの移行が進む中、これらのプラットフォーム上のデータバックアップのセキュリティはかつてないほど重要になっています。しかし、バックアップ管理者はこれらの貴重な「データ貯蔵庫」を保護するために十分なことをしているかどうかです！？

International Data Corporation (IDC)のレポートによると、セキュリティ・ソリューションとサービスに対する全世界の支出は、2023年には前年比12.1%増の2,190億ドルになるといわれています。この数字は相当なものだと思われるかもしれませんが、こうした投資が効果的に行われているかどうか、特にクラウドバックアップの安全性確保に向けて行われているかどうか、考えてみる価値はあるでしょう。

ネイティブ・ソリューションであるAWS BackupとAzure Backupの隠れたコストとリスク

多くの組織は、データを保護するためにAWS BackupやAzure Backupのようなビルトイン・バックアップ・サービスに依存しています。これらのサービスには確かにメリットもありますが、最初に見たよりもコストがかかる可能性が十分あります。また、これらのサービスには、サイバー・インシデント（事故）が発生した際に、迅速な業務復旧を妨げる可能性がある特定の制限があります。

ランサムウェア攻撃とバックアップ復旧の失敗による高コスト

クラウドバックアップとセキュリティの議論で考慮すべきもう一つの重要な側面は、ランサムウェア攻撃やバックアップ復旧の失敗によって発生する潜在的な損失です。これらのインシデントの影響は、直接的な金銭的損失にとどまらず、大きな生産性の損失や企業の信頼性の低下につながる可能性があります。

例えば、ランサムウェア攻撃は、企業の業務を停止させ、生産性を即に低下させます。このような攻撃によるダウンタイムとその後の復旧プロセスは、数日から数週間にわたってビジネスの継続性を阻害する可能性があります。 Cybersecurity Venturesによると、ランサムウェアに関連するダウンタイムの世界的なコストは、2021年には200億ドルを上っています。この数字は、2031年までに2650億ドルに増加すると予想されています。

同様に、バックアップの復旧(リカバリー)に失敗すると、生産性が大幅に低下します。重要なデータやシステムにアクセスできなければ、業務が停止し、問題が解決するまで財務上の損失が膨らみ続けます。

さらに、このようなインシデントは、企業の評判に長期的なダメージを与える可能性があります。データ漏えいが定期的にヘッドライン・ニュースを飾る時代において、顧客はますます個人情報のセキュリティに懸念を抱いています。たった一度のランサムウェア攻撃やバックアップ復旧の失敗が顧客の信頼を打ち砕き、顧客の喪失や市場シェアの低下につながる可能性が大きくあります。

クラウドバックアップソリューションの費用対効果を評価する際には、このような潜在的な損失を理解することが不可欠です。包括的で堅牢なバックアップとディザスタリカバリソリューションへの投資は、一見すると初期費用が高くつくように見えるかもしれませんが、長期的にはビジネスを壊滅的な財務的損失と評判の低下から救うことができます。

ビルドイン・バックアップサービス： それで十分か？

バックアップ戦略の主な目的は、データを保存するだけでなく、データの損失や漏洩が発生した場合に迅速な復旧を可能にすることです。この点で、ビルトイン・バックアップ・サービスは不十分かもしれません。AWS BackupやAzure Backupはデータを保存することはできますが、リソースをタイムリーにオンラインに戻すために必要な包括的なディザスタリカバリ機能が欠けていることが多いようです。

IDCのレポートでは、銀行や政府機関などの業界が2023年のセキュリティ製品・サービスへの投資をリードすると予測しています。厳格なデータ保護対策が求められるこれらの業界は、サイバーインシデント発生後に迅速に機能を復旧できなければ、業務や規制に大きな影響を及ぼす可能性があります。

マルチクラウド環境に対応したクラウドネイティブな統合バックアップソリューションの必要性

AWS BackupとAzure Backupは、それぞれのクラウド環境において堅牢なバックアップサービスを提供しているが、どちらのサービスもハイブリッドクラウドソリューションとして機能するように設計されていないことに注意する必要があります。

言い換えれば、AWS BackupはAWSエコシステム内で、Azure BackupはAzure環境内で最適に機能するが、本質的に複数のプラットフォームやクラウド環境間で機能するようには設計されてはいません。これは、データが異なるインフラに分散しているハイブリッド環境またはマルチクラウド環境で運用する企業にとって、決定的な制限となります。

例えば、ある企業があるワークロードにAWSを使用し、他のワークロードにAzureを使用している場合、2つの別々のバックアップソリューションを管理する必要があります。これは、バックアップとリカバリのプロセスにおける複雑さと潜在的な矛盾の増大につながる可能性が大きくあります。同様に、管理とモニタリングが最も重要であるため、AWSバックアップとAzureバックアップは効率的なデータ管理に必要なシームレスな統合を提供しない可能性もあります。

ハイブリッドクラウドにおけるAWS BackupとAzure Backupの限界を考えると、企業はマルチクラウドやハイブリッドクラウド環境で動作するように特別に設計された他のソリューションを検討する必要があるかもしれない。このようなソリューションは、今日のビジネスに必要な包括的でクロスプラットフォームなデータ保護を提供することができます。

バックアップ戦略を再考する時

このような課題を考えると、バックアップ管理者は戦略を再考する時期に来ています。ビルドインしたのバックアップサービスだけに頼っていては不十分かもしれません。その代わりに、包括的なディザスタリカバリ機能を提供し、より費用対効果の高い料金体系になる可能性のあるサードパーティバックアップソリューションへの投資を検討する時代に入っています。

ハイパーコネクテッドで、常時接続、24時間稼働の生産性サイクルにおいて、企業のハードウェア、ソフトウェア、サービスへの年間支出は、信頼性の高いクラウドネイティブサービスに大きく傾いています。このことは、企業が堅牢で効果的なバックアップとセキュリティ・ソリューションの重要性をますます認識するようになっていることを示唆しています。

結論として、セキュリティ支出の増加は確かな傾向を示しているが、バックアップ管理者にとっては、この投資が効果的に行われていることを確認することが重要です。企業がクラウドへの移行を進める中、AWSとAzureのバックアップを保護することは、すべての組織のサイバーセキュリティ戦略の最重要課題です。より多く投資するだけでなく、より賢く投資することが重要なのです。

タグ: ,