雲をもう一度見てみましょう。 プライベートクラウドとは何ですか?

一方ではコンピューティング能力の向上と x86 プラットフォーム仮想化テクノロジの開発、他方では IT アウトソーシングの普及により、ユーティリティ コンピューティング (公共サービスとしての IT) の概念が生まれました。 水道や電気の料金と同じように、必要なときに必要なだけ、それ以上は支払わないで、IT にも支払ってみてはいかがでしょうか。

現時点で、クラウド コンピューティングの概念、つまり「クラウド」からの IT サービスの利用、つまりこれらのリソースがどこからどのように来たのかを気にすることなく、外部のリソース プールから取得できます。 私たちが水道施設のポンプ場のインフラを気にしないのと同じです。 この時点までに、概念のもう一方の側面、つまり IT サービスの概念と、ITIL/ITSM のフレームワーク内でそれらを管理する方法も策定されていました。

クラウド (クラウド コンピューティング) の定義は数多く開発されていますが、これを究極の真実として捉えるべきではありません。これは、ユーティリティ コンピューティングが提供される方法を形式化するための単なる方法にすぎません。

• 「クラウド コンピューティングは、コンピューターのリソースと容量がインターネット サービスとしてユーザーに提供される分散データ処理技術です」 Wikipedia
• 「クラウド コンピューティングは、カスタマイズ可能なコンピューティング リソース (ネットワーク、サーバー、ストレージ、アプリケーション、サービスなど) の共有プールにオンデマンドで便利なネットワーク アクセスを提供し、最小限の管理労力または最小限の介入で迅速にプロビジョニングできるモデルです。サービスプロバイダー「NIST」
• 「クラウド コンピューティングは、セルフサービス モードで提供され、オンデマンドで管理される、スケーラブルで柔軟な分散物理リソースまたは仮想リソースのプールへのネットワーク アクセスを提供するパラダイムです。」 ISO/IEC 17788:2014。 情報技術 - クラウド コンピューティング - 概要と語彙。

NIST によると、クラウドには主に XNUMX つのタイプがあります。

1. IaaS - サービスとしてのインフラストラクチャ - サービスとしてのインフラストラクチャ
2. PaaS - サービスとしてのプラットフォーム - サービスとしてのプラットフォーム
3. SaaS - サービスとしてのソフトウェア

違いを非常に簡単に理解するために、Pizza-as-a-Service モデルを考えてみましょう。

NIST は、IT サービスがクラウド サービスとみなされるために必要な次の機能を定義しています。

• 広範なネットワーク アクセス - サービスには、最小限の要件でほぼ誰でもサービスに接続して使用できるユニバーサル ネットワーク インターフェイスが必要です。 例 - 220V 電気ネットワークを使用するには、標準のユニバーサル インターフェイス (プラグ) を備えたコンセントに接続するだけで十分です。これは、ケトル、掃除機、ラップトップのいずれであっても変わりません。
• 測定されたサービス - クラウド サービスの主な特徴は、サービスの測定可能性です。 電気のたとえに戻りますが、XNUMX か月間家に XNUMX 回いて、お茶を XNUMX 杯飲んだ場合、やかんを XNUMX 回沸騰させるコストまで、最小限の粒度で消費した金額とまったく同じ金額を支払うことになります。
• オンデマンドの自己構成サービス (オンデマンド セルフ サービス) - クラウド プロバイダーは、プロバイダーの従業員とやり取りすることなく、サービスをインテリジェントに構成できる機能を顧客に提供します。 やかんを沸騰させるために、事前にEnergosbytに連絡し、事前に警告し、許可を得る必要はまったくありません。 家が接続された（契約が締結された）瞬間から、すべての消費者は提供された電力を独立して処分することができます。
• 即時の弾力性 (急速な弾力性) - クラウド プロバイダーは、(一定の合理的な制限内で) 容量を即座に増減できる機能をリソースに提供します。 ケトルの電源がオンになると、プロバイダーはすぐに 3 kW の電力をネットワークに放出し、オフになるとすぐに出力をゼロに下げます。
• リソースのプーリング (リソース プーリング) - サービス プロバイダーの内部メカニズムにより、個々の発電能力をリソースの共通プール (プール) に結合し、さまざまなコンシューマーにサービスとしてリソースをさらに提供できます。 やかんのスイッチを入れるとき、私たちはその電力がどの発電所から供給されているかについてはほとんど心配しません。 そして他のすべての消費者は私たちと一緒にこの電力を消費します。

上記で説明したクラウドの特性は、天井から導き出されたものではなく、ユーティリティ コンピューティングの概念からの論理的な結論であることを理解することが重要です。 そして、公共サービスは、概念の枠組みの中でこれらの特性を備えていなければなりません。 何らかの特性が一致しない場合、サービスは悪化したり「有毒」になったりせず、ただ曇らなくなります。 では、すべてのサービスがそうすべきだと誰が言ったのでしょうか?

なぜこれについて個別に話しているのでしょうか? NIST の定義以来、過去 10 年間、その定義に従った「真の曇り」について多くの議論が行われてきました。 米国では、「法律の文言には対応するが、精神には対応しない」という表現が司法の分野で今でも時々使われている。クラウド コンピューティングの場合、主なものは精神であり、リソースは XNUMX つに分かれている。マウスのクリック。

上記 5 つの特性はパブリック クラウドにも当てはまりますが、プライベート クラウドに移行する場合、そのほとんどがオプションになることに注意してください。

• ユニバーサル ネットワーク アクセス (ブロード ネットワーク アクセス) - プライベート クラウド内で、組織は発電容量と消費者顧客の両方を完全に制御できます。 したがって、この特性は自動的に実行されると考えることができます。
• 測定されたサービスは、従量課金制というユーティリティ コンピューティングの概念の重要な機能です。 しかし、どのようにして組織に報酬を支払うのでしょうか? この場合、企業内で生成と消費が分離され、IT が提供者となり、事業部門がサービスの消費者になります。 そして決済は部門間で行われます。 XNUMX つの操作モードが可能です。チャージバック (実際の相互決済と財務の移動を伴う) とショーバック (リソースの消費をルーブルで報告する形式で、ただし財務の移動はなし) です。
• オンデマンドでの自己構成サービス (オンデマンド セルフ サービス) - 組織内に共通の IT サービスが存在する場合がありますが、その場合、特性は無意味になります。 ただし、事業部門に独自の IT スタッフまたはアプリケーション管理者がいる場合は、セルフサービス ポータルをセットアップする必要があります。 結論 - この特性はオプションであり、ビジネスの構造によって異なります。
• 瞬時の弾力性 (急速な弾力性) - プライベート クラウドを構成するための固定の機器セットにより、組織内ではその意味が失われます。 内部相互決済の枠組みにおいて限定的に使用することができます。 結論 - プライベート クラウドには適用できません。
• リソースのプーリング (リソース プーリング) - 現在、サーバー仮想化を使用していない組織は事実上ありません。 したがって、この特性は自動的に実行されると考えることができます。

Q: では、プライベート クラウドとは何ですか? 企業はそれを構築するために何を購入し実装する必要がありますか?

回答: プライベート クラウドは、IT とビジネスの相互作用の新しい管理モデルへの移行であり、80% の管理手段とわずか 20 のテクノロジーで構成されます。

設備投資に数億の石油をつぎ込む必要がなく、消費したリソースに対してのみ料金を支払い、簡単に参入できることで、新たな技術情勢が生まれ、億万長者企業が出現しました。 たとえば、現代の巨人である Dropbox と Instagram は、独自のインフラストラクチャを持たない AWS 上のスタートアップとして登場しました。

クラウド サービス管理ツールはより間接的なものになってきており、IT ディレクターの主な責任はサプライヤーの選択と品質管理であることを別途強調する必要があります。 これら XNUMX つの新しい責任を見てみましょう。

独自のデータセンターとハードウェアを備えた従来の重いインフラストラクチャの代替として登場したクラウドは、一見して軽いです。 クラウドに入るのは簡単ですが、通常、出口の問題は回避されます。 他の業界と同様に、クラウド プロバイダーはビジネスを保護し、競争を困難にしようと努めています。 唯一の深刻な競争の瞬間は、クラウド サービス プロバイダーの最初の選択時にのみ発生します。その後、プロバイダーは顧客が離れないようにあらゆる努力をします。 さらに、すべての努力がサービスの品質やその範囲に向けられるわけではありません。 まず第一に、独自のサービスの提供と非標準のシステム ソフトウェアの使用が、他のプロバイダーへの切り替えを困難にしています。 したがって、サービスプロバイダーを選択する際には、そのプロバイダーからの移行計画（実際には本格的な DRP - 災害復旧計画）を同時に策定し、データストレージとバックアップのアーキテクチャを検討する必要があります。

CIO の新しい責任の 95 番目に重要な側面は、サプライヤーからのサービスの品質管理です。 ほぼすべてのクラウド プロバイダーは、独自の内部指標に従って SLA に準拠していますが、これは顧客のビジネス プロセスに非常に間接的な影響を与える可能性があります。 したがって、重要な IT システムをクラウド プロバイダーに移行する場合、独自の監視および制御システムの実装が重要なプロジェクトの 36 つになります。 SLA の話題を続けると、大多数のクラウド プロバイダーは、SLA の不履行に対する責任を月々のサブスクリプション料金または支払いの一部に限定していることを強調する必要があります。 たとえば、AWS と Azure は、可用性のしきい値 100% (月あたり 30 時間) を超えると、サブスクリプション料金を XNUMX% 割引し、Yandex.Cloud は XNUMX% 割引します。

https://yandex.ru/legal/cloud_sla_compute/

そしてもちろん、クラウドを実行しているのはアマゾンクラスのマストドンやヤンデックスクラスのゾウだけではないことを忘れてはなりません。 雲も小さくなり、猫やネズミほどの大きさになります。 CloudMouse の例で示したように、クラウドが単に取得されて終了する場合もあります。 補償や割引は受けられません。データの完全な損失以外は何も得られません。

クラウド インフラストラクチャにおけるビジネス クリティカル性の高い IT システムの実装に関する上記の問題を考慮して、「クラウド リパトリエーション」現象が近年観察されています。

2020 年までに、クラウド コンピューティングは膨らんだ期待のピークを過ぎ、コンセプトは失望のどん底に向かいつつあります (Gartner ハイプ サイクルによる)。 研究によると IDC и 451研究 最大 80% の企業顧客が、次の理由から負荷をクラウドから自社のデータ センターに戻し、また戻すことを計画しています。

• 可用性とパフォーマンスを向上させます。
• コストを削減;
• IS 要件に準拠するため。

何をすべきか、そしてすべてが「本当に」どうなっているのか？

雲が本格的に、そして長い間やって来たことは間違いありません。 そして年々彼らの役割は増大していきます。 しかし、私たちは遠い未来ではなく、2020 年の非常に明確な状況に生きています。 あなたがスタートアップ企業ではなく、従来の企業顧客である場合、クラウドをどうすればよいでしょうか?

1. クラウドは主に、予測不可能な、または顕著な季節的負荷を伴うサービスの場所です。
2. ほとんどの場合、予測可能な安定した負荷を持つサービスは、独自のデータセンターで維持する方が安価です。
3. テスト環境や優先度の低いサービスを備えたクラウドの利用を開始する必要があります。
4. クラウドへの情報システムの配置の検討は、クラウドから別のクラウド (または独自のデータセンターに戻る) に移動するための方法論の開発から始まります。
5. 情報システムをクラウドに配置することは、管理するインフラストラクチャのバックアップ スキームの開発から始まります。

出所： habr.com