半構造化データは、構造化データと非構造化データの中間に位置します。リレーショナルテーブルにはきっちりと収まりませんが、タグ、キー、メタデータ、またはネストされた階層構造を含んでおり、機械が読み取れる形式となっています。代表的な例としては、JSON、XML、APIペイロード、イベントログ、テレメトリデータなどが挙げられます。
構造化データと非構造化データの比較[ブログ]
構造化データは固定されたスキーマに従い、行と列で保存されます。SQLを使用してクエリを実行したり、ダッシュボードで活用したりすることができます。非構造化データにはあらかじめ定義された形式がなく、文書、メール、画像、チャットログなどが含まれます。構造化データはレポート作成やトランザクション処理に最適です。非構造化データは、文脈の把握、検索、知識の抽出に適しています。
構造化データと非構造化データの比較[ブログ]
Veeamによると、76%の企業がクラウド上でデータ損失を経験している一方で、半数の企業は、ファイルが大量に削除された場合、データを復元することは不可能だと考えている。これらは、Microsoft 365のデータ保護に関して組織が犯しがちな過ちである。
クラウドアプリケーションは、組織にさまざまなメリットをもたらします。特に、ビジネスに不可欠なファイルやサービスにどこからでもアクセスできるため、従業員はオフィスにいてもリモートワーク中でも、場所を問わず生産性を維持できます。しかし、クラウドを活用することは、バックアップやデータ保護に関する新たなミスやエラーを招く可能性もあります。
多くのITリーダーは、OneDrive、SharePoint、Exchange Onlineがデータを自動的に保護してくれると想定しています。60%が、Microsoft 365がファイルを自動的に保護していると信じています。しかし、実際はそうではありません。
Microsoft 365の責任分担モデルに基づくと、完全なデータバックアップは提供されません。組み込みの復元ツールは、削除されたファイルを30日から90日間保存した後に、完全に削除してしまいます。
ランサムウェアは企業にとって依然として大きな問題となっています。特に、サイバー犯罪者がデータを暗号化するだけでなく、身代金が支払われない場合は削除すると脅迫してくる場合です。管理者アカウントへのリモートからの不正アクセスは、リスクをさらに高めます。
残念ながら、Microsoft 365はクラウドデータに対する自動的なランサムウェア保護を提供しておらず、攻撃者が要求する身代金を支払わない場合、被害者は大量のファイル削除に直面することになります。そして、身代金を支払ったとしても、攻撃者がデータを削除してしまう可能性は依然として残っています。
Climb Cloud Backup (CCB)の時間制限のない自動バックアップ機能により、削除から数年経った後でもデータの復元が可能です。一方、CCBの不変バックアップは別のクラウドに保存されるため、ハッカーがファイルを完全に削除することはできず、ランサムウェア攻撃によるデータ削除から組織を保護します。
ITリーダーは、外部からのサイバーセキュリティ脅威に強く注力しています。しかし、危険はそれだけではありません。内部脅威は、外部からの脅威よりもデータにとってさらに大きなリスクとなり得ます。これは、管理者のミスによるデータ損失のような不注意なケースもあれば、不満を抱いた従業員が意図的にデータを消去するようなケースもあります。
クラウドアプリケーションはグローバルなエコシステムで稼働していますが、多くの企業は自社のデータ保護プロセスが現地の規制に準拠しているかどうかを確認していません。一方、Microsoftの組み込みツールには、プライバシー関連法規で要求される長期的なデータ保持機能が備わっておらず、組織が数百万ドル規模の罰金や訴訟リスクにさらされる可能性があります。
CCB for Microsoft 365は、GDPRへの準拠を確保し、HIPAAのデータ保護要件を満たし、クラウドデータに対するSOC 2準拠をサポートします。さらに、業界固有のニーズに合わせた柔軟な保存ポリシーも提供します。
多くの企業は、OneDriveやSharePointにバックアップを保存すれば適切だと考えていますが、それは元のデータと同じMicrosoft 365クラウドにバックアップを保存することを意味します。このシナリオでは、Microsoft 365アカウントが侵害された場合、攻撃者は元のデータとバックアップの両方を削除できてしまいます。CCBは、バックアップを独立して保存し、ハイブリッドストレージオプションを提供することでこの問題を解決します。これにより、必要に応じてバックアップをローカルサーバーにコピーすることが可能になります。
一部の企業は、バックアップを作成しているだけで十分だと考えていますが、データ復旧計画が機能するかどうかをテストすることは決してありません。サイバー攻撃やサービス停止といった実際のインシデントに見舞われて初めて、バックアップが不完全であることや、そもそもデータ復旧計画が策定されていないことに気づくのです。クライム/CCBなら、定期的な復旧シミュレーションによるデータの常時復旧性の確保と、即時のファイル復元機能により、組織がこの問題を回避できるよう支援します。
これら6つのミスは、Microsoft 365のデータを深刻なリスクにさらします。IT管理者はこれらの問題を理解し、データを確実に保護するために必要な対策を講じる必要があります。
CCB for Microsoft 365は、これらのリスクを排除する包括的なソリューションを提供します。今すぐデモをリクエストして、データの保護を確実なものにしましょう！
Nutanixと「Hyper-V ＋ StarWind vSAN」は、どちらもHCI（ハイパーコンバージドインフラ）的な構成を実現できますが、その設計思想やターゲット、コスト構造は大きく異なります。
それぞれの特徴を比較したメリット・デメリットをまとめました。
| 比較項目 | Nutanix (Cloud Infrastructure) | Hyper-V ＋ StarWind vSAN |
| 主なターゲット | 中大規模〜エンタープライズ | 小規模〜中規模、エッジ、ROBO |
| スケーラビリティ | 非常に高い（数百ノード以上可能） | 中程度（2ノード構成に強み、数〜十数台） |
| 管理の容易さ | Prism による統合管理（極めて容易） | Hyper-VとStarWindを個別に管理 |
| ライセンスコスト | 高め（機能・サポート込み） | 低め（既存資産の活用が可能） |
| ハードウェア | 専用アプライアンスまたは認定品 | 汎用IAサーバ（自由度が高い） |
Nutanixは「インフラを意識させない」ことを目的としたフルスタックのHCIソリューションです。
圧倒的な運用性: 「Prism」という管理ツールにより、ストレージ、仮想マシン、ネットワーク、バックアップ、アップデート（ワンクリック・アップグレード）を一つの画面で完結できます。
データローカリティ: データをVMが動いているノードに優先的に配置するため、ネットワークトラフィックを抑え、安定したパフォーマンスを発揮します。
ハイパーバイザーの選択肢: 独自のAHV（無料）のほか、ESXiやHyper-Vも選択可能です。
高度な機能: 重複排除、圧縮、イレイジャーコーディング、セルフヒーリング（自己修復）などが標準で高度に組み込まれています。
導入コストが高い: ライセンス費用に加え、サポート費用もエンタープライズ価格となります。
最小構成のハードル: 基本的に3ノード以上が推奨されます（2ノード構成も可能ですが制約があります）。
リソース消費: 管理用の仮想マシン（CVM）が各ノードで一定のメモリとCPUを消費するため、小規模環境ではオーバーヘッドが目立ちます。
StarWindは、Windows Serverの標準機能であるHyper-Vを補完し、安価に共有ストレージ環境を作るためのソフトウェアです。
圧倒的なコストパフォーマンス: Windows Serverのライセンスを有効活用でき、Nutanixに比べてライセンス費用を大幅に抑えられます。
2ノード構成に最適: StarWindは2台のサーバを直接LANケーブルで結ぶ（スイッチレス）構成が得意で、最小限の機器で冗長化が可能です。
既存ハードウェアの流用: 特定のベンダーに縛られず、一般的なIAサーバで構築できるため、ハードウェア選定の自由度が高いです。
軽量な動作: NutanixのCVMに比べ、StarWindのサービスはリソース消費が少なく、ハードウェア性能をVMに回せます。
管理の分離: Hyper-Vの管理（Failover Cluster Manager）と、StarWindのストレージ管理、さらにハードウェアの管理が別々になるため、運用に手間がかかります。
拡張性の限界: 数十台規模まで拡張する場合、管理の複雑性が増し、Nutanixのようなシームレスな拡張は難しくなります。
スキルセットが必要: Windows ServerとiSCSIストレージの両方の知識が必要であり、トラブル時の切り分けもユーザー側で行う場面が増えます。
Nutanix が向いているケース:
管理の手間を極限まで減らしたい。
将来的にノードをどんどん増やしていく予定がある。
ミッションクリティカルなシステムで、手厚いメーカーサポートが必要。
キーワード: 「運用自動化」「スケーラビリティ」「エンタープライズ」
Hyper-V ＋ StarWind vSAN が向いているケース:
予算が限られている。
2ノード〜4ノード程度の小規模なクラスタを作りたい。
Windows Serverの管理に慣れているエンジニアがいる。
キーワード: 「コスト削減」「省スペース」「小規模拠点」
補足: Nutanixも最近は小規模向けのライセンスを提供していますが、それでも「シンプルさ」と「安さ」では依然として StarWind ＋ Hyper-V に軍配が上がることが多いです。
TempDBのデータファイルはいくつ使用すべきですか？
実用的な目安としては、論理CPUコア1つにつき1つのTempDBデータファイル（最大8つまで）を使用し、すべてのファイルを同じサイズに設定することです。それ以降は、競合状況や監視結果に基づいて変更を検討してください。
データベースに複数のトランザクションログファイルを使用すべきですか？
ほとんどの場合、必要ありません。適切なサイズで、増分が固定された単一のログファイルの方が管理が容易であり、通常はパフォーマンスも向上します。主な例外は、トランザクション・ログがディスク全体を埋め尽くしてしまう場合です。ログファイルを拡張する余地がなく、ログファイルが満杯になったためにそのデータベースへの書き込みが停止している場合、別のディスクに2つ目のログファイルを追加することは、短期的な対策として妥当な場合があります。それでも、データベースを単一のログファイルに戻すために、後でログを再構築するよう努めます。
パーセンテージベースの自動拡張は避けるべきですか？
必ずしもそうとは限りませんが、予測不可能性が生じます。固定サイズの自動拡張の方が理屈が分かりやすく、ファイルが大きくなるにつれてサイズが急激に跳ね上がるのを防げます。
ストレージが本当にボトルネックかどうかはどうやって判断すればよいですか？
待機統計とファイルレベルのI/Oメトリクスを長期的に確認してください。レイテンシや待機が特定のファイルや操作と一致している場合、調査すべき具体的な箇所が特定できます。
すでに過負荷状態にある場合、どこから手をつければよいでしょうか？
可視性とリスクが最も高い箇所から着手してください。具体的には、TempDB、トランザクションログのサイズ設定、および基本的なI/Oモニタリングです。これらの変更は、パフォーマンスや安定性の向上、そしてチームへの時間的還元という点で、多くの場合、すぐに成果をもたらします。
SQL ServerにおけるTempDBを一言で言うと、「SQL Serverが作業場として使う、共有のゴミ捨て場兼スクラップ帳」です。
サーバが起動するたびに新しく作成され、再起動すると中身はすべて消去されるという、非常に特殊なシステムデータベースです。
SQL Serverは、自分自身のメモリだけでは処理しきれない時や、一時的な保管場所が必要な時にTempDBを使います。
一時オブジェクトの保存: ユーザーが作成した一時テーブル（#temp）やテーブル変数などを置く場所です。
作業領域: 大きなデータのソート（並べ替え）、ハッシュ結合（JOIN処理）、重複削除（DISTINCT）などを行う際の作業スペースとして使われます。
行バージョン管理: 「スナップショット分離レベル」などを使っている場合、変更前の古いデータを一時的にここに避難させます。
再起動でリセットされる: SQL Serverサービスを再起動するたびに、TempDBは削除され、初期サイズで再作成されます。そのため、重要なデータをここに永続保存することはできません。
ログ記録が最小限: 通常のデータベースと違い、リカバリ（復旧）を想定していないため、書き込みパフォーマンスを上げるためにトランザクションログの記録が簡略化されています。
全ユーザーで共有: 一つのインスタンス内にあるすべてのデータベースが、この一つのTempDBを共有します。
設定がパフォーマンスに直結する: みんなが使う「作業場」なので、ここが渋滞するとシステム全体の速度が低下します。
下記の記事では、他のバックアップコピーに影響を及ぼす災害が発生した場合に備えて、MSP360のバックアップの「ゴールデンコピー」を保護するために、WasabiのCovert Copyを使用する手順について説明します。
詳細は↓
https://docs.wasabi.com/docs/wasabis-covert-copy-feature-with-msp360-backup
主な新規機能情報：
●HPE Morpheus Software全体で単一のバイナリによるインストールが可能になりました。
●システムレベルの資産を一元管理するための新しいVMEシステムライブラリカタログが追加されました。
●ArubaCxDssセキュリティグループによるネットワークとセキュリティが強化されました。
●Zerto HPE VM DRのサポートが追加されました。
●パフォーマンスを最大化するため、NUMA L3境界に基づく自動vCPU配置。
●HVMネットワークのサポートが拡張され、Standard、Private、Data、Overlayネットワークがネイティブでサポートされるようになりました。
●ハイパーバイザーコンソールでのキーボードレイアウトのサポートが強化されました。
●HVMクラスタのアップグレード – アップグレードワークフローにより、クラスタのライフサイクル管理が合理化されました。
●Alletra MPプラグインの更新内容は多すぎて、ここではすべて記載できません。
●一括移行の改善：より高速で信頼性の高い移行が可能になりました。
HPE Zerto SoftwareはAWSレジリエンスコンピテンシーパートナーとして認められ、サイバーリカバを含むレジリエンス設計、運用、復旧においてAWSの最高技術基準を満たしたことでコアレジリエンスの指定を取得しました。この検証により、クラウドIT専門家はAWS認証を受けたコンサルティングおよびエンジニアリングサービスを信頼して災害復旧、サイバー復旧、移行戦略を効率化できると保証します。
この組合せはコストを抑えつつ2ノードでの可用性（HA）を確保したい中小企業やエンジニアの検証環境において、非常に人気のある組み合わせです。
StarWind VSANはもともとWindows (Hyper-V) 環境に強いイメージがありましたが、現在はLinuxベースのCVM（Controller VM）を提供しており、KVMユーザの間でも一般的に使われています。
Proxmox VE ユーザ: KVMベースの仮想化OSであるProxmoxと組み合わせ、2台のサーバーだけで共有ストレージ不要のクラスタ（HCI）を構築するケースが非常に多いです。
oVirt / Red Hat Virtualization ユーザ: 企業向けのKVM管理プラットフォームで、共有ストレージとしてStarWindを採用し、高可用性を実現しています。
コスト重視の企業: 高価な物理SAN（外付けストレージ）を導入できない環境で、汎用サーバのローカルディスクを冗長化するために採用されています。
KVM標準の冗長化構成（CephやDRBDなど）と比較して、以下の点が評価されています。
2ノード構成が可能: Cephなどは通常3ノード以上が推奨されますが、StarWindは「2ノード＋外部ウィットネス（監視役）」で安定したHA構成が組めるため、ハードウェアコストを最小化できます。
管理の容易さ: KVM/Linuxのコマンド操作に不慣れでも、Web GUIやWindowsの管理コンソールからストレージの同期状態を確認・管理できる点が好まれています。
パフォーマンス: 同期レプリケーションの効率が良く、SQL ServerやファイルサーバーなどのI/O負荷が高い業務アプリにも耐えうると評価されています。
多くのユーザが以下のような構成で運用しています。
構成方法: KVMホスト上に「StarWind CVM (Controller VM)」という専用の仮想マシンをデプロイ。
ストレージ提供: CVMが各ホストのディスクをネットワーク経由でミラーリングし、iSCSIターゲットとしてKVMホストに再提供する。
ネットワーク: レプリケーション専用の10GbE以上の直結ラインを確保し、遅延を最小化する構成が一般的です。
ITレビューサイト（G2やTrustRadiusなど）では、以下のような声が見られます。
「Proxmoxクラスタを最小構成で組む際、Cephよりもセットアップが簡単で、パフォーマンスも安定している。」 「古いサーバーを再利用してKVMホストにしているが、StarWindを入れるだけでエンタープライズ級の共有ストレージが手に入った。」
dpa_sql_job_failure.txt
DPAには、ジョブステップのいずれかが失敗した際にトリガーされるデフォルトの「データベース・ジョブ失敗」アラートが用意されています。しかし、一部のジョブは条件分岐ロジックで設計されており、あるステップが失敗しても、後続のステップに処理が移行され、最終的に正常に完了する場合があります。そのような場合、ジョブは最終的に意図した通りに完了しているにもかかわらず、デフォルトのアラートが発動してしまう可能性があります。この拡張アラートは、真のジョブ失敗のみに焦点を当て、ジョブ全体が正常に完了しなかった場合に通知します。
アラートを作成するには、アラート > アラートの管理に移動し、新しいカスタム SQL アラート – 複数の数値リターンを追加します。以下の設定を使用してアラートを構成し、添付のコードにある SQL をSQL ステートメントフィールドに貼り付けます。ステータスが正常ではない場合にトリガーされるよう、通知ポリシーを必ず更新してください。
1. AI Query Assistとは？
AI Query Assistは、生成AIと実行プランのコンテキストを活用して、パフォーマンス重視のSQL書き換えを提案するSolarWindsの機能です。
2. なぜ一般的なAIツールを使わないのですか？
一般的なAIツールには実行コンテキストが欠けていたり、機密性の高いクエリの詳細が漏洩する恐れがあります。AI Query AssistはSolarWindsのワークフローに組み込まれており、データベースのチューニングを目的に設計されています。
3. AI Query Assistはどのように機能しますか？
パフォーマンスの低いクエリを選択し、分析に送信すると、最適化されたバージョンと元のクエリを並べて確認でき、提案された変更点についての明確な説明も表示されます。
4. AI Query Assist はどこで利用できますか？
AI Query Assist は、SQL Sentry、Database Performance Analyzer (DPA)、および SolarWinds Observability SaaS で利用可能です。
5. 手動によるクエリチューニングの代わりになりますか？
いいえ。書き換えの段階を迅速化しますが、提案された SQL を展開するかどうかは、引き続きユーザー自身が確認、テスト、判断する必要があります。
パフォーマンスチューニングのようなことに関しては、「無駄な時間」という言葉にはあまり共感できません。確かに、誰もがそう感じることはあるでしょう。特に、何時間も費やした挙句、最初から間違った方向に進んでいたと気づいた時はなおさらです。
その代わり、それを「投資した時間」、つまり何かを学ぶために費やした時間だと捉えるようにすべきです。次にこう尋ねるべきです。「週に何時間、何かを学ぶために費やしていますか？」。これによって大抵、研修についての議論が始まり、そこから「実務を通じた」研修へと話題が移り、気がつけばまさに目指していた場所、つまりSQL文のパフォーマンスチューニングに費やす時間について話し合っているのです。
では、その時間はどれくらいになると見積もりますか？まだ答えないでください。開発、デプロイ、保守、本番サポート、管理など、あらゆる分野について考えてみてください。気づけば、時間の75％近くを単に処理を高速化しようとすることに費やしていることに気づくかもしれません。それはかなりの時間です！
もし、システムを高速化するためにそれほど多くの時間を費やすのであれば、できるだけ効率的に作業を進めたいと思うはずです。それを実現するには、待機イベントを活用します。
考え方は単純です。クエリが何を待っているのかが分かれば、そのボトルネックを取り除き、クエリの実行速度を向上させることができるのです。
もし、ランサムウェアによってバックアップチェーン全体が暗号化されてしまう悪夢、あるいはさらに悪いことに、オフサイトのコピーまで被害に遭ってしまうという悪夢を見て、冷や汗をかいて目が覚めた経験はありませんか？ 優れたチームであっても、こうした事態は起こり得ます。すべてがクラウドや脆弱なストレージ上に保存されているため、たった1回の侵害で数週間分の復旧手段が失われてしまうのです。ハッカーは、主にあなたのバックアップインフラを標的としています。（断言します）。だからこそ、私はオンプレミス環境を維持しつつ、セキュリティを多層的に強化するソリューションに情熱を注いでいます。本日は、ローカルストレージをランサムウェア対策済みの金庫へと変える画期的なソリューション、StarWind Virtual Tape Library（VTL）について深く掘り下げていきます。Veeam Backup & Replication（または他のツール）と組み合わせることで、テープをオフサイトに送る必要なく、黄金の「3-2-1」バックアップルールに完璧に適合します。なぜこれが次なる補完的なストレージ戦略となるべきか、技術的な側面から段階を追って解説していきます。
このシンプルなルールを再確認しましょう。「3-2-1ルール」は単なる流行語ではありません。実世界の災害から生まれた、データ耐障害性の業界標準なのです。
これを守らないと後悔することになります。
しかし、クラウドが完璧ではない場合もあります。クラウドによるオフサイト保存は便利ですが、インターネットに依存した復元や、潜在的なセキュリティ侵害、ダウンタイムのリスクにさらされます（最近のAzureやAWSのダウンタイムで、何百もの企業がオフラインになったことを覚えていますか？）。
そこで登場するのがStarWind VTLです。これはローカルディスク上でテープをエミュレートし、物理的なテープを使わずに「異なるメディア」を実現すると同時に、速度と管理性を確保するためにすべてをオンプレミスに保持します。このソリューションがどのようにしてこのルールを完璧に満たすかについては、こちらで詳しく説明します。
主なアーキテクチャの特徴：
エミュレーション層： 独自開発のソフトウェアを使用して、SCSIテーププロトコル（例：IBMやHPのライブラリ）をエミュレートします。1台あたり最大10,000本の仮想テープをサポートし、各テープの容量は100GBから100TBまで対応しています。RAIDプールにより、ペタバイト規模まで拡張可能です。
ストレージバックエンド：Linux（軽量なフットプリントが推奨）またはWindows上に展開し、冗長性のためにソフトウェアRAIDを使用します。ローカルドライブからプールを作成し、VTLデバイス用のボリュームを割り当てます。
設計による不変性：仮想テープはWORM（Write-Once-Read-Many）に準拠しています。一度書き込まれるとロックされ、ルートレベルの脅威による上書きも不可能です。これにより、バックアップは論理的にエアギャップが確保され、ランサムウェアが変更可能なターゲットを攻撃できなくなります。
階層化とレプリケーション： 長期保存のためのAWS S3/GlacierまたはBackblaze B2へのオプションのクラウドゲートウェイ。バックアップは当初オンプレミスに保持され、その後オフサイトへの自動レプリケーションが行われます。
仮想化の状況は変化しており、柔軟性はかつてないほど重要になっています。組織が従来のハイパーバイザーに代わる現代的でコスト効率の良い選択肢を求める中、HPE Morpheus VM Essentials(VME)はハイブリッドクラウド時代に向けた強力なKVMベースのソリューションとして台頭しています。
HPE Morpheus Softwareにおける初のカーネルベースの仮想マシン(KVM)ベースのハイパーバイザーに対するプラットフォームサポートが拡張されたHPE Zerto Software v10.8.11。このリリースは、HPEから企業の災害復旧とサイバーの回復力を企業仮想化に提供します。
なぜこれが重要なのか:
長年にわたり、Zertoは秒単位のRPOと分単位のRTOの基準を設定してきました。この支援をHPE VMEに拡大することで、企業はサイバーのレジリエンスを犠牲にすることなくインフラを近代化する自由を与えられます
🔹 ジャーナルベースのブロックレベルレプリケーションによる継続的データ保護(CDP)— スナップショットではなく
🔹 5〜15秒ごとに回復ポイントが奪取され、数千のチェックポイントが最大30日間保持されます
🔹 RPOは秒単位で測定されます。RTOは数分単位で測定されます — 個々のVMまたは複数VMのアプリケーショングループ全体に対して
🔹 チェンジブロックトラッキングによるほぼ同期レプリケーション — 本番ストレージへのパフォーマンス影響ゼロ
🔹 仮想保護グループ(VPG)を用いた複数VMワークロード間のアプリケーション一貫性回復
データ主導の現代において、組織はリソースの最適化、コスト削減、および事業継続性の確保のために、仮想化技術への依存度を高めています。しかし、仮想環境における効率的なデータ保護とシームレスな管理への需要は、依然として極めて重要です。HPEの「Morpheus VM Essentials（HPE VME）」と、Veeamの業界をリードするデータ保護プラットフォームを統合することで、これらの重要なニーズに驚くほど容易かつ効率的に対応する強力なソリューションが実現します。ここでは、VeeamとのHPE VME統合の重要性と価値、エージェントレスバックアップの利点、そしてこれらのテクノロジーを導入することが現代のIT環境においてなぜ画期的な変化をもたらすのかについて解説します。
ブロードコムによるVMwareをめぐる騒動
現在のVMwareの市場環境は、ブロードコムによる買収に伴うライセンスおよびサポートの大幅な変更の影響を受けています。ブロードコムは新しいサブスクリプションモデルを導入し、これにより顧客のコストは3倍から15倍に跳ね上がり、利用可能な製品バンドルの数も減少しました。永久ライセンスの廃止や技術サポートの縮小は、顧客に大きな不安をもたらしています。調査によると、VMware顧客の32％が代替ソリューションを積極的に検討しており、2028年までに30％がVMware vSphereハイパーバイザーから他のプラットフォームへ移行すると予想されています。
代替ソリューションへの関心を高めている主な要因には、セキュリティ機能、スケーラビリティ、コスト、およびコンテナ化やクラウド戦略との整合性が挙げられます。組織は、VMの無秩序な増加、運用の複雑化、ベンダーロックインへの懸念といった課題に直面しており、ITチームはハイブリッドおよびマルチクラウド環境とシームレスに統合できる、費用対効果が高く柔軟な仮想化ソリューションの評価を迫られています。
VMwareの代替候補としては、以下が挙げられます：
HPE Morpheus VM Essentials ソフトウェア（VM Essentials）は、VMware および HPE 環境全体における仮想化管理を統合・簡素化するために設計された、コスト効率に優れた KVM ベースのハイパーバイザーソリューションです。HPE のハイパーバイザーは HVM と呼ばれ、15 年以上にわたるイノベーションを通じて HPE によって開発・強化されてきました。本ソリューションは、VMware vSphere StandardおよびEnterprise Plusエディションに代わるコスト効率の高い選択肢を求める組織を対象としており、統合されたハイブリッドクラウド運用、コスト削減、および管理の簡素化を重視しています。
HPE Morpheus VM Essentialsは、ローカルおよびネットワーク接続型の両方の外部ストレージをサポートし、効率的なリソース利用のための分散ワークロード配置機能に加え、VMの自動フェイルオーバーを可能にする高可用性を備えています。また、ホストおよびVMストレージのライブマイグレーション、アフィニティおよびアンチアフィニティグループによるワークロードのバランス調整、ワークロードの高速化のためのGPUパススルー、クラッシュ一貫性のあるVMバックアップおよび復元機能を統合して提供します。
ここでは、VMware vSphere StandardおよびEnterprise Plusエディションに対する競争力のある代替ソリューションとして、以下の機能を提供します：
つい最近まで、Nutanix AHV への移行中に VMware ESXi のバックアップを維持するには、万が一古いバックアップを復元する必要が生じた場合に備えて、スタンバイ状態のステージング・ポッド用に VMware ライセンスを維持しておく必要がありました。この余分なハードウェアとライセンスは、バックアップがコンプライアンス義務の対象となる限り、導入・維持し続ける必要がありました。
これは、ほとんど使用されることのないソリューションに対して、多大なコストがかかることになります。
VeeamとNutanixは、Nutanix AHVへの移行を可能な限りスムーズかつコスト効率の高いものにするため、新たな共同ソリューションを発表しました。
今後、お客様は既存のバックアップを作成時の状態のまま維持する（例：Veeamのアーカイブストレージの一部としてカタログ化されたVMwareバックアップ）という選択肢を得られ、余分なライセンス費用、ハードウェア費用、およびIT関連費用を削減できるようになります。
長期バックアップにアクセスできれば、それで十分です。コンプライアンスを維持するために、「万が一に備えて」という名目のライセンス費用を支払う必要はありません。
主なメリット：
コスト削減の機会がある理由は以下の通りです：
これはお客様にとって大きなメリットです。VeeamとNutanixは、インフラストラクチャおよび運用コストの削減を目的としたソリューションで協力しています。
オブジェクトストレージ、ブロックストレージ、ファイルストレージは、クラウドストレージの3大選択肢であり、それぞれが独自の特性を持ち、その用途を決定づけています。本ガイドでは、オブジェクトストレージ、ブロックストレージ、ファイルストレージを比較し、それぞれの違い、長所と短所、およびユースケースに焦点を当てて解説します。
主なポイント：オブジェクトストレージ、ブロックストレージ、ファイルストレージの比較
・オブジェクトストレージは、画像、動画、PDFなどの非構造化データを、メタデータ（識別情報や属性）が付随した個別の単位である「オブジェクト」として保存します。オブジェクトは、「バケット」と呼ばれるコンテナに整理されます。
・ブロックストレージは、データを「ブロック」と呼ばれる小さな単位に分割し、限られたメタデータと共に保存することで、高速かつ効率的なアクセスを実現します。
・ファイルストレージは、データをファイルシステムに保存します。ファイルシステムは階層構造をとっており、データの共有アクセスを可能にします。
専門家の分析：データストレージアーキテクチャの種類
・一般的なファイルストレージ：Dropbox、Google Drive、iCloudなどの多くの人気クラウドストレージサービスは、SaaS（Software as a Service）として提供されるファイルストレージです。これらはファイルシステムを採用しており、階層構造内のフォルダにデータを保存します。
・ネットワーク接続ストレージ（NAS）：ネットワーク接続ストレージ（NAS）は、ハイブリッドクラウドを導入する業界において最も広く利用されているファイルストレージの1つです。市場規模は500%以上成長し、2023年の約220億ドルから2033年には1,380億ドル以上に拡大すると予測されています。1
・データストレージアーキテクチャの選択：ワークロードに適したデータストレージを選択する際は、データ量、アクセス頻度、コスト、パフォーマンス要件、および共有アクセス性に注意を払ってください。
Blobストレージは、オブジェクトストレージの一種です。「Blob」は「binary large object（バイナリ大容量オブジェクト）」の略で、音声ファイル、画像、動画ファイルなど、テキストではない大容量のバイナリデータを指します。
オブジェクトストレージは、Blobを含むデータを元のアップロード形式のままメタデータと共に保存するのに対し、Blobストレージはバイナリ大型オブジェクトを保存するオブジェクトストレージの一種です。つまり、Blobストレージはオブジェクトストレージの一種ですが、すべてのオブジェクトストレージがBlobストレージであるわけではありません。
・メディアの保存： 動画や画像などのメディアファイルはファイルサイズが非常に大きくなるため、大量のストレージ容量が必要となります。オブジェクトストレージシステムの料金が比較的安価であるため、Backblaze B2のようなサービスを利用すれば、大規模なメディア保存においても通常、コスト効率に優れています。これは特に中国のクラウドストレージサービスに当てはまり、これらのサービスでは、大規模なメディア保存向けに手厚い無料プランや競争力のある価格設定を提供していることがよくあります。
・バックアップ： クラウドオブジェクトストレージは通常、冗長化されており、異なるゾーンやリージョンにある多数のデバイスに分散して保存されます。そのため、システム障害やデータの永久的な損失リスクに強く、重要なデータのバックアップに最適です。
・ビッグデータ分析： オブジェクトストレージは、大量の非構造化データを元の形式のまま保存できるため、ビッグデータ分析のデータソースとして機能するデータレイクの構築に最適です。
・仮想マシン： 仮想マシンのファイルシステムとしてフォーマットされた後、オペレーティングシステムやスワップ領域など、仮想マシンを稼働させるために必要なコンピューティングリソースがブロックストレージ上にインストールされます。
・データベース： ブロックストレージは効率的かつ高速なデータ転送に最適化されているため、さまざまな種類のデータベース、特にリレーショナルデータベースなど、高いI/Oパフォーマンスを必要とするデータベースに最適です。
・ハイパフォーマンスコンピューティング： ハイパフォーマンスコンピューティングでは、コンピュータクラスタやスーパーコンピュータを使用して、高度な計算処理のためのデータ処理速度を向上させます。ブロックストレージは、低レイテンシと高スループットを特徴としており、特にランダムなデータアクセスが必要な場合に、この目的に最適です。
・ハイブリッドアクセス管理： ハイブリッドクラウド環境を構築する際、オンプレミスのファイルシステムを、同じファイルシステムを持つクラウドファイルストレージと容易に統合できます。
・コンテナストレージ： ファイルストレージはコンテナ内で使用され、クラスタ内のコンテナ間で共有データへのアクセスが可能になります。
・データベースのバックアップ： ファイルストレージソリューションのファイルシステムは、データベースに容易に接続し、バックアップ用のコピーを作成できます。
ブロックストレージ、ファイルストレージ、オブジェクトストレージの違いは、ブロックストレージがデータを分割して等サイズのブロック単位で保存するのに対し、ファイルストレージはデータを階層的なファイルシステムで整理・保存し、オブジェクトストレージはデータを元の形式のまま拡張可能なストレージユニットに保存する点にあります。
ブロックストレージは、データを等しいサイズのブロックに分割して保存するのに対し、BLOBストレージ（オブジェクトストレージのもう1つの種類）は、画像、動画、音声ファイルなどのデータを、メタデータとともに元の形式のまま、フラットなネームスペースに保存します。
Amazon S3はオブジェクトストレージサービスであり、データを「バケット」と呼ばれるコンテナ内のオブジェクトとして保存します。
タグベースの自動化により、組織はAWSリソースに割り当てられたメタデータに基づいて、バックアップ操作を動的に管理できます。「Environment=Prod」や「Backup=true」などのリソースタグを使用することで、AWS BackupやAWS Data Lifecycle Managerなどのバックアップツールは、手動での更新を行うことなく、バックアップポリシーへのリソースの包含や除外を自動的に行うことができます。
これは、インスタンスやボリュームが頻繁に作成および終了されるオートスケーリング環境や一時的な環境において特に有用です。タグベースのルールにより、指定された条件を満たすすべての新規起動リソースが自動的に保護されるため、一貫性が向上し、運用上のオーバーヘッドが削減されます。
増分バックアップでは、前回のバックアップ以降に変更されたデータのみをキャプチャするため、バックアップ時間、ストレージ使用量、およびネットワーク帯域幅を削減できます。Amazon EBSスナップショットやAWS BackupなどのAWSサービス、およびVeeamやMSP360などのサードパーティ製ツールは、増分バックアップの仕組みに対応しています。
データが頻繁に変更される動的なワークロードにおいて、増分バックアップは、フルバックアップを繰り返すことなくデータ保護を維持するための効率的かつ費用対効果の高い方法を提供します。また、復元を高速化し、変更頻度の高い環境において極めて重要な、より厳格な復旧時点目標（RPO）をサポートします。
ライフサイクル管理により、バックアップやスナップショットを、Amazon S3 Glacier や Glacier Deep Archive などの低コストなストレージクラスへ、時間の経過とともに自動的に移行させることができます。AWS Backup や S3 ライフサイクルポリシーなどのサービスは、保存期間やアクセス頻度に基づいた自動的な階層化をサポートしています。
頻繁にバックアップが生成される動的なワークロードの場合、ライフサイクルルールを使用することで、コンプライアンスや監査の目的でバックアップを保持しつつ、古くアクセス頻度の低いバックアップをアーカイブすることで、ストレージコストを抑制できます。このアプローチにより、アクティブなストレージ容量を圧迫したり、不要な費用が発生したりすることなく、長期的な保存が可能になります。
アカウント間およびリージョン間のバックアップ戦略は、バックアップデータをプライマリ環境から分離することで、耐障害性を高めます。AWS Backupは、リージョンやAWSアカウントをまたぐバックアップコピージョブをサポートしており、特定エリアでの障害、セキュリティ侵害、または誤削除からの保護に役立ちます。
この分離は、リソースの入れ替わりが激しく、運用ミスのリスクが高まる動的なワークロードにおいて極めて重要です。バックアップを異なるアカウントやリージョンに保存することで、組織は影響範囲を縮小し、災害復旧体制を強化し、データ主権や規制要件を満たすことができます。
AWS CloudFormation、Terraform、Pulumi などの Infrastructure as Code (IaC) ツールを使用すると、アプリケーションのインフラストラクチャと同様に、バックアップ構成を定義し、バージョン管理を行うことができます。バックアップポリシーやリソースのタグ付けを IaC テンプレートに直接組み込むことで、チームはデプロイプロセスの一環として一貫したバックアップ手順を徹底することができます。
これは、インフラストラクチャが頻繁に起動・停止される動的なワークロードにおいて特に有益です。バックアップポリシーの適用を自動化することで、手動による介入やデプロイ後のスクリプトに依存することなく、新しいリソースがデフォルトで保護されるようになります。また、環境全体での監査可能性と再現性が向上し、コンプライアンスの遵守と運用上の健全性の維持が促進されます。
AWS上の動的なワークロードを保護するには、従来のバックアップ戦略以上のものが必要です。クラウドネイティブインフラストラクチャの一時的な性質、頻繁なデータ変更、および自動スケーリングに対応するには、ポリシー主導型でタグを認識し、インフラストラクチャのプロビジョニングと緊密に統合されたツールと手法が求められます。
AWSのネイティブサービスと高度なサードパーティ製ソリューションを組み合わせることで、組織は環境に合わせて拡張可能な、耐障害性が高く監査可能なバックアップ戦略を維持できます。自動化、リージョン間の分離、およびInfrastructure-as-Codeによるオーケストレーションを導入することで、最も動的なワークロードであっても、データ保護がその変化に確実に対応できるようになります。
Climb Cloud Backup & Security (Acronis Cyber Protect)は、Amazon EC2インスタンス向けのバックアップ、災害復旧、サイバー保護を統合したソリューションです。自動化されたバックアップスケジュール、迅速な復旧、高度な脅威防御機能を、企業およびマネージドサービスプロバイダー向けに設計された単一のプラットフォームに統合しています。このプラットフォームは、アプリケーション一貫性のあるバックアップ、暗号化、および不変ストレージを利用したランサムウェア対策をサポートしています。
主な機能は以下の通りです：
包括的なEC2バックアップ：AWS EC2上で実行されているデータ、システム状態、およびアプリケーションを保護します
柔軟なスケジュール設定：ワークロードのパターンに合わせてカスタマイズされた手動および自動のバックアップスケジュールをサポート
増分および差分バックアップ：変更されたデータのみをバックアップすることで、ストレージ使用量と帯域幅を削減
AES-256暗号化：コンプライアンスとプライバシー保護のため、転送中および保存中のデータを保護
ランサムウェア対策ストレージ：不変ストレージを使用して、バックアップの不正な削除や暗号化を防止
N2WSは、ダイナミックなAWS環境向けに特別に設計された、クラウドネイティブなバックアップおよび災害復旧プラットフォームです。スナップショットのみを扱うツールとは異なり、N2WSはポリシー駆動型の自動化、アカウント間の分離、不変性、および環境全体の復旧オーケストレーションを単一のコンソールに統合しています。安全なAPI呼び出しを使用してAWSアカウント内で直接動作するため、データ、キー、および権限に対する完全な制御を維持できます。
EKSクラスター、マルチアカウントアーキテクチャ、またはコンプライアンス主導のワークロードを管理するITシステム管理者やクラウドエンジニアにとって、N2WSは、ストレージコストを膨らませることなく、バックアップを驚くほど簡単に、復旧を極めて高速に、そしてランサムウェア対策を高セキュリティで実現することに重点を置いています。
アカウント間およびリージョン間の分離：専用のDRアカウントを作成してバックアップを本番環境から分離し、影響範囲を縮小するとともに、誤削除や悪意のある削除から保護します。
不変のバックアップとコンプライアンスロック：改ざん防止型のバックアップ保持ポリシーを適用し、管理者による変更や削除さえも防止することで、ランサムウェアへの耐性と規制コンプライアンスをサポートします。
環境全体の復旧オーケストレーション：VPC、サブネット、ルーティングテーブル、VPN、ロードバランサー、セキュリティグループを含む環境全体を、正しい起動順序で復元します。
AWS EKS バックアップおよびリカバリ：EKS ネームスペースおよびクラスターに対してポリシー主導型の保護を提供し、ロールバックや移行シナリオに合わせて、同一または別のクラスターへの柔軟な復元を可能にします。
統合されたマルチアカウントおよびマルチクラウド管理：ツールやワークフローを切り替えることなく、単一のコンソールからAWS、Azure、Wasabiのバックアップを管理します。
きめ細かなスケジューリングとタグベースの自動化：秒単位のスケジューリング精度と、タグを使用したリソースの動的な包含をサポートします（オートスケーリングや一時的なワークロードに最適です）。
1つのポリシー、複数の保持期間：単一のポリシー内で週次および月次の保持スケジュールを設定でき、バックアップの肥大化を防ぎ、ストレージ使用率を最適化します。
コスト最適化機能：スナップショットのアーカイブ、ライフサイクル自動化、即時クリーンアップ、リソーススケジューリングを備え、ストレージの過剰プロビジョニングを防止します。
自動化されたDR（災害復旧）演習：本番ワークロードに影響を与えることなく、非破壊的な復旧シナリオを実行し、災害への備えを検証します。
きめ細かなファイル単位の復元：環境全体の復旧を必要とせずに、個々のファイル、フォルダ、ボリューム、またはインスタンス全体を復元します。
お客様のAWSアカウント内で実行：お客様自身のAWS環境内で安全なAPI呼び出しを通じて動作し、データの完全な管理と主権を確保します。
Amazon Elastic Kubernetes Service（EKS）における動的ワークロードは、通常、需要に応じて自動的にデプロイ、スケーリング、および終了されるコンテナ化されたマイクロサービスで構成されています。EKSにおけるバックアップ戦略では、永続データ（例：ポッドにアタッチされたボリューム）とクラスターの状態（例：デプロイメント、サービス、コンフィグマップ）の両方を考慮する必要があります。VeleroやEBSと統合されたAWS Backupなどのツールは永続ボリュームのデータを取得できますが、クラスター構成の復元には、GitOpsの実践やHelm、TerraformなどのIaCツールがよく使用されます。バックアップソリューションは、動的に変化するネームスペース、ボリューム、ノードグループを識別し、追跡できる必要があります。
AWS Lambda関数は本質的に一時的かつステートレスですが、S3、DynamoDB、SQSなどの動的なデータソースに関連付けられたイベントを処理したり、トリガーしたりすることがよくあります。Lambdaベースのワークロードに対するバックアップ戦略は、関連するデータや構成アーティファクト（関数コード、環境変数、IAMロール、イベントソースのマッピング）の保護に重点を置きます。AWS CloudFormation または AWS Serverless Application Model (SAM) を使用して、インフラストラクチャをコードとしてキャプチャできます。誤削除やデプロイエラーが発生した場合に迅速な復旧を確実にするためには、関数定義の定期的なエクスポートとバージョン管理が不可欠です。
オートスケーリンググループ（ASG）は、定義されたポリシーに基づいてEC2インスタンスを起動および終了させるため、アクティブなリソースのセットは非常に動的になります。ASGインスタンスは頻繁に置き換えられるため、バックアップは、基盤となる起動テンプレート、構成ファイル、およびEBSボリュームのような永続ストレージに重点を置きます。AWS BackupおよびDLMを使用すると、タグベースのポリシーを使用してEBSボリュームのスナップショットを自動化できます。バックアップ戦略では、起動構成で使用されるゴールデンAMIに加え、共有ボリュームや外部データベースに保存されていないインスタンス固有のデータも確実に取得する必要があります。
サーバーレスアーキテクチャでは、Lambda、API Gateway、Step Functions、DynamoDB、S3 などの複数のマネージドサービスが、疎結合なアプリケーションとして組み合わされることがよくあります。これらのワークロードをバックアップするには、マルチサービスアプローチが必要です。各コンポーネントの状態と構成に加え、DynamoDBテーブルやS3バケットなどのデータ永続化レイヤーもキャプチャする必要があります。DynamoDB PITRやS3レプリケーションが一般的に使用されます。IaCやアプリケーションテンプレート（例：AWS CloudFormation StackSets）をサポートするツールはアーキテクチャ定義の保持に役立ち、AWS Backupのような集中管理型サービスは、対応している場合、データ保護を処理できます。
ダイナミック・ワークロードとは、需要の変化に応じてリソースを自動的に増減させるクラウドベースのアプリケーションやサービスのことです。この弾力性はクラウドネイティブアーキテクチャの中核となる機能であり、多くの場合、オートスケーリンググループ、サーバーレス関数、あるいはKubernetesのようなコンテナオーケストレーションプラットフォームによって実現されます。
これらのワークロードは、通常、疎結合かつ分散型です。単一のモノリシックなアプリケーションとして構築されるのではなく、APIを介して通信する、より小規模で独立したコンポーネント（多くの場合マイクロサービス）で構成されています。これにより、耐障害性とスケーラビリティが向上する一方で、バックアップや復元操作の際の状態や依存関係の追跡が複雑になります。
動的なワークロードは頻繁に変化します。リソースは、CI/CDパイプラインやインフラストラクチャ・アズ・コード（IaC）のデプロイの一環として、自動的に作成、変更、または終了される場合があります。この急速な変動により、バックアップ戦略は手動設定に依存するのではなく、自動化され、ポリシー主導でなければなりません。バックアップポリシーは、新しいリソースが出現した際に動的に検出し、保護する必要があります。
動的ワークロードのバックアップにおける主要な課題の一つは、「スナップショット」の取得が困難であることです。インフラストラクチャやデータの状態が時間経過とともに一貫して維持される静的システムとは異なり、動的環境には、その状態が分単位で変化する一時的なコンポーネントが存在します。そのため、より頻繁なバックアップ、より短いRPO（復旧時点目標）、そして固定されたアーキテクチャを前提とせずに分散サービス全体にわたるデータをキャプチャできるツールが必要となります。
HPE Zerto は HPE Morpheus Enterprise および HPE Morpheus VM Essentials Manager と統合され、HVM 環境における継続的なレプリケーションとディザスタリカバリを実現します。現在、レプリケーションは HVM 間環境でのみサポートされています。HVM 環境では、以下の主要機能がサポートされています：
復旧操作中、HPE ZertoはQEMUゲストエージェントの存在を確認できない場合でも、Re-IPの実行を試みます。エージェントがインストールされていない場合、Re-IP操作は失敗します。
回避策：
Re-IPをサポートするための前提条件として、すべての保護対象VMにQEMUゲストエージェントがインストールされている必要があります。
すべてのVMにQEMUゲストエージェントがインストールされていることを確認してください。
VPGの作成および編集ワークフロー中、保護対象VMの電源が入っており、QEMUゲストエージェントが検出されている場合にのみ、IP設定の構成が可能となります。
特定のLinuxディストリビューション（CentOSやRocky Linuxなど）では、SELinuxポリシーが厳格化されているため、QEMUゲストエージェントコマンド「guest-exec」の実行が阻止され、Re-IP操作が失敗します。
回避策：
SELinuxポリシーの適用状況はLinuxディストリビューションによって異なり、Re-IPをサポートするためにVMの追加設定が必要になる場合があります。
Re-IPを許可するためにSELinuxの強制レベルを下げる手順あり。
ユーザーは、リバースプロテクトの「VPGの編集」画面において、フェイルオーバー実行中にのみホスト／データストアの設定を変更できます。
フェイルオーバーのコミット後は、リカバリ ホスト/データ ストアの変更をサポートしていないため、設定済みのホスト/データ ストアを変更することはできません。
HPE Zerto で保護されている VM に対してストレージ ライブ マイグレーションを実行するには、VM の電源をオフにし、マイグレーションを実行してから、電源をオンにする必要があります。
