ハイブリッド クラウド: 初心者パイロットのためのガイド

こんにちは、ハブロビ人！ 統計によると、ロシアのクラウドサービス市場は絶えず力を増しています。 テクノロジー自体は決して新しいものではないにもかかわらず、ハイブリッド クラウドはこれまで以上にトレンドになっています。 多くの企業は、状況に応じて必要なものも含めた膨大なハードウェア群をプライベートクラウドの形で維持管理することがどの程度実現可能なのか疑問に思っている。

今日は、どのような状況でハイブリッド クラウドの使用が正当化されるのか、またどのような場合に問題が発生する可能性があるのか​​について説明します。 この記事は、これまでハイブリッド クラウドを本格的に扱った経験はなく、すでに検討しており、どこから始めればよいかわからない人にとって役立ちます。

記事の最後には、クラウド プロバイダーの選択とハイブリッド クラウドのセットアップに役立つヒントのチェックリストを提供します。

興味のある方はぜひ参加してください！

プライベート クラウド VS パブリック: 長所と短所

企業がハイブリッドへの移行を促す理由を理解するために、パブリック クラウドとプライベート クラウドの主な機能を見てみましょう。 まず第一に、何らかの形でほとんどの企業に関係する側面に焦点を当てましょう。 用語の混乱を避けるために、主な定義を以下に示します。

プライベート (またはプライベート) クラウド は IT インフラストラクチャであり、そのコンポーネントは XNUMX つの企業内にあり、その企業またはクラウド プロバイダーが所有する機器上にのみ配置されています。

パブリッククラウド は IT 環境であり、その所有者は有料でサービスを提供し、クラウド内のスペースを全員に提供します。

ハイブリッドクラウド 複数のプライベート クラウドと複数のパブリック クラウドで構成され、そのコンピューティング能力は共有されます。

プライベートクラウド

プライベート クラウドにはコストが高いにもかかわらず、無視できない利点がいくつかあります。 これには、高い制御性、データセキュリティ、リソースと機器の動作の完全な監視が含まれます。 大まかに言えば、プライベート クラウドは、理想的なインフラストラクチャに関するエンジニアのアイデアをすべて満たします。 いつでもクラウド アーキテクチャを調整したり、そのプロパティや構成を変更したりできます。

外部プロバイダーに依存する必要はありません。すべてのインフラストラクチャ コンポーネントはお客様側に残ります。

しかし、強力な賛成論にもかかわらず、プライベート クラウドは開始時とその後のメンテナンスに非常に費用がかかる可能性があります。 すでにプライベートクラウドを設計する段階で、将来の負荷を正しく計算する必要があります...最初に節約すると、遅かれ早かれリソースの不足と成長の必要性に直面するという事実につながる可能性があります。 また、プライベート クラウドの拡張は複雑で費用のかかるプロセスです。 新しい機器を購入し、接続して構成する必要があるたびに、これには数週間かかることがよくありますが、パブリック クラウドではほぼ瞬時にスケーリングできます。

設備費に加えて、ライセンスや人材の財源も確保する必要がある。

場合によっては、「価格/品質」のバランス、より正確には「拡張とメンテナンスのコスト/得られるメリット」が最終的に価格の方にシフトすることがあります。

パブリッククラウド

プライベート クラウドを所有しているだけの場合、パブリック クラウドは外部プロバイダーに属し、そのコンピューティング リソースを有料で使用できます。

同時に、クラウドのサポートとメンテナンスに関連するすべてのことは、強力な「プロバイダー」の肩にかかっています。 あなたの仕事は、最適な料金プランを選択し、期限までに支払いを行うことです。

比較的小規模なプロジェクトにパブリック クラウドを使用すると、独自の機器群を維持するよりもはるかに安価になります。

したがって、IT専門家を維持する必要がなくなり、財務リスクが軽減されます。

いつでも、クラウド プロバイダーを自由に変更し、より適切な、またはより収益性の高い場所に移動することができます。

パブリック クラウドの欠点に関して言えば、ここにあるものはすべて完全に予想されています。クライアント側での制御が大幅に制限され、大量のデータを処理する際のパフォーマンスが低下し、プライベート クラウドに比べてデータ セキュリティが低くなります。これは、一部の種類のビジネスでは重要になる可能性があります。 。

ハイブリッドクラウド

上記の利点と欠点が交差するのがハイブリッド クラウドです。ハイブリッド クラウドは、事実上、少なくとも XNUMX つのプライベート クラウドと XNUMX つ以上のパブリック クラウドを組み合わせたものです。 一見すると (そして二度見しても) ハイブリッド クラウドは、いつでもコンピューティング パワーを「インフレ」させ、必要な計算を実行し、すべてを「吹き飛ばす」ことを可能にする賢者の石のように見えるかもしれません。 雲じゃないよ、デヴィッド・ブレインだ！

実際には、すべてが理論どおりに美しいです。ハイブリッド クラウドは時間とコストを節約し、多くの標準および非標準のユースケースを備えています...しかし微妙な点があります。 その中で最も重要なものを次に示します。

まず第一に、パフォーマンスの面も含めて、「自分の」クラウドと「他人の」クラウドを正しく接続する必要があります。 ここでは、特にパブリック クラウド データ センターが物理的に離れている場合、または別のテクノロジーで構築されている場合に、多くの問題が発生する可能性があります。 この場合、遅延のリスクが高く、場合によっては重大な事態に陥る可能性があります。

第二に単一アプリケーションのインフラストラクチャとしてハイブリッド クラウドを使用すると、すべての面 (CPU からディスク サブシステムまで) でパフォーマンスが不均一になり、耐障害性が低下します。 同じパラメータを持つ XNUMX つのサーバーが異なるセグメントに配置されていると、異なるパフォーマンスが示されます。

第3に、すでに上で述べた、「外国」ハードウェアのハードウェア脆弱性 (Intel アーキテクトに熱烈な挨拶) やクラウドの公共部分におけるその他のセキュリティ問題について忘れないでください。

第四にハイブリッド クラウドを使用すると、単一のアプリケーションをホストする場合、耐障害性が大幅に低下する恐れがあります。

特別ボーナス: XNUMX つではなく XNUMX つのクラウド、および/またはそれらの間の接続が一度に「切断」できるようになりました。 そして一度に多くの組み合わせで。

これとは別に、ハイブリッド クラウドで大規模なアプリケーションをホストする際の問題についても言及する価値があります。
ほとんどの場合、パブリック クラウドで、たとえば 100 GB の RAM を搭載した 128 台の仮想マシンを入手することはできません。 ほとんどの場合、そのような車を10台もくれる人はいません。

はい、パブリッククラウドはゴムではありません、モスクワ。 多くのプロバイダーは単純にそのような空き容量を確保しておらず、これは主に RAM に関係します。 好きなだけプロセッサ コアを「描画」でき、物理的に利用可能な容量の何倍もの SSD または HDD 容量を提供できます。 プロバイダーは、一度にボリューム全体を使用せず、途中でボリュームを増やすことができることを望んでいます。 ただし、RAM が十分でない場合、仮想マシンまたはアプリケーションが簡単にクラッシュする可能性があります。 そして、仮想化システムでは常にそのようなトリックが許可されるわけではありません。 いずれにせよ、この出来事の展開を覚えておき、これらの点を「陸上」プロバイダーと話し合う価値があります。そうしないと、負荷のピーク時（ブラック フライデー、季節負荷など）に取り残される危険があります。

要約すると、ハイブリッド インフラストラクチャを使用する場合は、次の点に留意してください。

• プロバイダーは、常に必要な容量をオンデマンドで提供できるわけではありません。
• 要素の接続に問題と遅延が発生しています。 どのインフラストラクチャの部分がどのような場合に「ジョイント」を通じてリクエストを行うかを理解する必要があり、これはパフォーマンスと可用性に影響を与える可能性があります。 クラウドには XNUMX つのクラスター ノードが存在するのではなく、別個の独立したインフラストラクチャが存在すると考えた方がよいでしょう。
• 景観の大部分で問題が発生するリスクがあります。 ハイブリッド ソリューションでは、どちらかのクラウドが完全に「脱落」する可能性があります。 通常の仮想化クラスターの場合、失うリスクはせいぜい XNUMX 台のサーバーだけですが、ここでは一晩で一度に多くのサーバーを失うリスクがあります。
• 最も安全なのは、パブリック部分を「エクステンダー」としてではなく、別のデータセンター内の別のクラウドとして扱うことです。 確かに、この場合、実際にはソリューションの「ハイブリッド性」を無視していることになります。

ハイブリッド クラウドの欠点を軽減する

実際、この写真はあなたが思っているよりもはるかに楽しいものです。 最も重要なことは、優れたハイブリッド クラウドを「調理」するコツを知ることです。 主なものをチェックリスト形式で示します。

• アプリケーションの遅延の影響を受けやすい部分 (OLTP 負荷下のキャッシュやデータベースなど) をメイン ソフトウェアとは別にパブリック クラウドに移動しないでください。
• アプリケーションのこれらの部分全体をパブリック クラウド上に配置しないでください。パブリック クラウド上に配置しないと動作が停止します。 そうしないと、システム障害の可能性が数倍に増加します。
• スケーリングするときは、クラウドのさまざまな部分にデプロイされたマシンのパフォーマンスが異なることに留意してください。 スケーリングの柔軟性も完璧とは程遠いでしょう。 残念ながら、これはアーキテクチャ設計の問題であり、完全に取り除くことはできません。 仕事への影響を軽減するように努めることしかできません。
• パブリック クラウドとプライベート クラウドの間の物理的な近接性を最大限に確保するようにしてください。距離が短いほど、セグメント間の遅延が少なくなります。 理想的には、クラウドの両方の部分が同じデータセンター内に「存在」します。
• 両方のクラウドが同じネットワーク テクノロジーを使用していることを確認することも同様に重要です。 Ethernet-InfiniBand ゲートウェイには多くの問題が発生する可能性があります。
• 同じ仮想化テクノロジーがプライベート クラウドとパブリック クラウドで使用されている場合、これは明らかにプラスになります。 場合によっては、プロバイダーと合意して、再インストールせずに仮想マシン全体を移行することができます。
• ハイブリッド クラウドの使用を収益性の高いものにするには、最も柔軟な価格設定のクラウド プロバイダーを選択してください。 何よりも、実際に使用されたリソースに基づいています。
• データセンターによるスケールアップ: 容量を増やす必要がある場合は、「XNUMX 番目のデータセンター」を構築し、そこに負荷をかけます。 計算は終わりましたか? 余分な電力を「消して」節約します。
• プライベート クラウドの拡張中、または単に一定期間だけ、個々のアプリケーションとプロジェクトをパブリック クラウドに移動できます。 確かに、この場合、ハイブリッド性はなく、独自のクラウドの有無にまったく依存しない一般的な L2 接続のみが使用されます。

代わりに、結論の

それだけです。 プライベート クラウドとパブリック クラウドの機能について説明し、ハイブリッド クラウドのパフォーマンスと信頼性を向上させる主な機会について検討しました。 ただし、クラウドの設計は、企業のビジネス目標とリソースによって決定された決定、妥協、慣例の結果です。

私たちの目標は、読者が自分の目標、利用可能なテクノロジー、財務能力に基づいて、適切なクラウド インフラストラクチャの選択を真剣に検討するよう動機付けることです。

ハイブリッド クラウドに関するご経験をコメント欄で共有していただければ幸いです。 あなたの専門知識が多くの初心者パイロットに役立つと確信しています。

出所： habr.com