プライベートな「クラウド」について：通常、ロシアで何がどのように行われるか、教育プログラム、主な問題

私の仕事は、 仮想化ソリューションを設計し、ロシア企業向けのプライベート「クラウド」を実装することです。 まず、このようなプライベートな「クラウド」とは何ですか：

• これらは、お客様の地域のITサービスです。
• さらに、これらは進化的に「クラウド」に到達したサービス、つまり分散コンピューティングのサービスです。

なぜこれが必要ですか？ 実際には4つの理由があります。

1. 鉄の節約：「クラウド」を使用すると、鉄のこのようなインフラストラクチャがなければ少なくとも3倍の量を必要とする場合に、1組の鉄で何百ものプロジェクトをスピンできます。 まあ、将来的には鉄の交換に問題はありません。
2. ライセンスの節約：ライセンス条件がユーザーではなくマシン上で示されることがよくありました。 そして、マシンが物理的に単一で、ユーザーが5〜6人の場合、大幅に安くなります。
3. インフラストラクチャ展開の速度要件。 適切に構成されたプライベート「クラウド」から、わずか数分で簡単に地域に新しいオフィスを立ち上げることができます。 または、痛みなくスケーリングします。
4. Magical 152-FZおよびその他の多くの標準：処理のためにPDを他の誰かに渡すことは常に可能ではありませんが、自宅で農場を展開する必要があります。

次に、これが通常どのように行われ、どのようなレーキが発生するかを見てみましょう。 はい。以下に、それらの構築の実践に関するセミナーへの無料招待がまだあります。

プライベートの「クラウド」を注文するのは誰ですか？

原則として、これらは大企業であり、すでにプロセスはかなり成熟しています。 彼らはすでにサービスアプローチを実装していますが、これらすべてをプライベートな「クラウド」で自動化する必要があります。 サービスアプローチは、IT領域の各部分がユーザーのサービスと見なされる場合です。 たとえば、仮想マシンが必要です-必要な権限と設定を持つ別のインスタンスを放棄しただけです。 一元化および統合。 などなど。

最初の顧客-IT部門

原則として、IT部門は独自の「クラウド」が必要であることを最初に理解します。 これは通常発生します。彼らは自分自身、同僚、請負業者の要求に応じて仮想マシンを調達します（ところで、請負業者にインフラストラクチャへのアクセスを許可することは最も一般的なタスクの1つです）。 ある時点で、プラットフォーム（PaaS）を作成する必要があることが明らかになり、必要な操作がほとんどユーザー自身によってワンクリックで実行されると、すべてがSaaSになります。 並行して、これらすべてのプロセスが説明され、それらのコストがふりをされています。 なんで？ 節約を知っているので、そのような決定の必要性をリーダーシップに証明することははるかに簡単です。 ビジネスに優しいお金が表示されます。 たとえば、メールボックスのコストは非常に高く、来年は新しいユーザーが非常に多くなります。 主な要因が表示されます-価格。 そして、私を信じて、多くの人は通常のIT部門の「シャーマン」の言語ではなく、お金の言語への移行に非常に満足しています。

大きな頭痛はテスト環境です

大企業の主なサービスの1つは、 さまざまな開発環境の提供の自動化です 。 たとえば、石油およびガス、銀行、または電気通信環境では、「ドライ」データでは新しい何かをテストできないため、ほとんどすべての主要プロジェクトにテスト環境が必要です。 たとえば、制御された環境で昨日の基地のキャストに従って運転し、出力に何があるかを確認する必要があります。 そのようなプロジェクトが1つしかない場合、特定のサーバー群が際立っており、誰もがそれを追いかけます。



しかし、すでに多数のプロジェクトがある場合は、仮想テスト環境が必要です。 さらに、必死に必要。 リソースを消費しないように、展開、構成、強制終了、または凍結する必要があります。 多くのプロジェクトがあり、多くの手作業が必要です。 セキュリティ上の質問があります。

会社のインフラ

企業がITへの完全なサービスアプローチに切り替える準備ができたら（西側のほとんどの企業が経済的実現可能性のためだけに行うように）、一般ユーザーに必要なものはすべてプライベートな「クラウド」で構成されます。 原則として、これはメール、バックアップ、データストレージ用のディスク領域、仮想マシンです。



別の問題は、拡張性です。 たとえば、顕著な季節ピーク（観光客、または大or日のピークなど）があるコールセンターの場合、1年に2週間の仕事のために大量の鉄とライセンスを購入しないことは論理的です-彼らは非常に拡張しやすい仮想リソースを使用します。

ピークタスク

ビッグデータ （通信料請求、保険料の計算など）には、月に一度発生するタスクがあり、重い脱穀サーバーも完全に殺します。 たとえば、私が知っていた計算の1つは、最初の仮想化サイクルの後の数か月間、物理的な機器で行われました-数週間、そして今では「クラウド」のすべての無料リソースが正確にこの計算に従事しています（同時に、残りのプロセスを遅くしません）-すべてが数日で行きます。

それから新しいプロジェクトがやってくる

銀行がプロジェクトを立ち上げ、それがどれだけのリソースを必要とするかについて完全に不明確であるとします。 社内の新興企業は新しく、誰も言うことができないため、理解できない-500人、顧客ベースの1％、さらには2番目に1人の顧客です。 したがって、一方で高価な鉄を最初に購入するのではなく、予想されるまたは予期しないピークに備えて保険をかけることは論理的です-その場合、インフラストラクチャを高価に変更する必要があります。 したがって、ここでは「クラウド」内のすべてをねじることも論理的です。 しかし、私たちは銀行と152-FZについて話しているので、非公開です。

顧客向けのSaaS

企業が、アーキテクチャからの移行のために「クラウド」をデプロイしたくないが、請負業者または顧客にサービスを提供することを気にしないこともあります。 この場合、一般的なインフラストラクチャとは別のプライベートな「クラウド」が起動されます。たとえば、ジョブや重要なデータへのアクセスを巨大な広告代理店で配信したり、クライアントバンクへの安全なアクセス、銀行クライアントの経理や買収を設定したりできます。

珍しいケース

ある大規模なエネルギー企業では、状況は一般的に標準的でした-数百の子会社、多くの支店、協会内の個々の企業の非常に複雑な構造。 これらはすべて、1つのITサービスによって提供されます。 みんなが対処しており、すべてが賢明にセットアップされていますが、1つの問題があります。 具体的には、ITサービス（たとえば、仮想マシンやサーバー上の場所）の場合は、関連付け内で支払いを行う必要があり、このために何らかの方法で請求書を発行する必要があります。 特定のリクエストにどれだけのリソースが費やされているかを誰も明確に確認できないため、これを行うのは非現実的です。 そして予測することも。 その結果、彼らはプライベートな「クラウド」を展開およびセットアップし、それぞれのリソース計算へのシンプルかつ透過的な移行を可能にしました。 今では、誰もがリアルタイムでどれだけ借りているのかを見て、見ることができるので、議論は終わりました。 請求は公正です。 これは非常に優れた金融仲裁人であり、すべてを正常に戻すことができました。 それに加えて、彼らは徐々に他の機能を既に完成した「クラウド」に固定し始めました。



弊社では、計算単位の1つがプロセッサ時間です。たとえば、各プロジェクトには「クラウド」リソースの使用のための割り当てがあり、それを渡しません。 割り当ては、プロジェクトの優先度によって決まります。 これは私たちにとって非常に便利です。なぜなら、プロジェクトの重要性を判断する際に必要なものすべてが接続される管理システムにも結び付けられているからです。



管理インターフェイスからこのような分布がどのように見えるかを次に示します。







そして、これは内部計算の例です：

通常、プライベートクラウドはどのように実装されますか？

実際には-困難を伴います。 私が出くわした主な問題は、すべてがどのように機能し、どのように有益であるかについての単純な誤解です。 IT部門から私に手紙を書いて、経営陣に見せるために計算を依頼することがあります。 彼らは計算を行い、私の計算を行います-そして、これらの紙片のうち2つだけを一緒に（したがって、従業員と外部企業の意見があるように）納得させます。 それでも決定が下される場合、実装手順は次のとおりです。



1.最初に、ITサービスは何をどのようにすべきかを話し合います。

サービスカタログが作成された後、どの部分が既に実装されており、どの部分が実装されていないかを調べます。 たとえば、オンデマンドで仮想マシンを割り当てることは、エンドユーザー向けではなく、開発者向けまたは請負業者向けのサービスです。 したがって、自動化され、詳細に記述されたSLAです。 または、100人のユーザー向けにファームを拡張します-ファームの別の部分と接続する必要があります。 などなど。



2.各サービスの詳細。



3.次に、すでに存在し、「クラウド」の展開に使用できるものを確認します。

たとえば、サービスデスクシステムがあります。 これはすべて、プライベート「クラウド」の現実に規定されています。



4.次に標準的なこと。

これはベンダーの選択であり、コストがかかり、ハードウェア、作業、「クラウド」を作成するための製品ライセンス、統合のためのペニーに対する正確な財務計画です。



5.それでは、直接、動作します。

実装例

私たち自身の経験についてお話します。 新しいソリューションを開発したり、ボックスソリューションをリチューニングするプロジェクト会社として、開発環境とテスト環境が必要です。 2006年から2007年まで、ラボ全体は鉄のサーバーで構成されていました。つまり、実際には、各プロジェクトで仕様を策定し、どこかで注文し、倉庫でサーバーを見つけ、それらを持ち込み、取り付け、接続する必要がありました。 十分な電力がなかった場合、これは再び注文、待機、配送になります。 ほぼ石器時代。



その後、VMware仮想化プラットフォームが登場しました（この時点では事実上の代替手段はなかったことに注意することが重要です）。 いくつかの強力なサーバーを購入し、それらにVMware Serverを配置して、すべての人の生活を楽にすることにしました。 その後、展開速度の点では本当に簡単になりましたが、それほどではありません。 これらのすべてが仮想サーバーを管理するメカニズムが存在するにもかかわらず、これらすべてが事実上手動で展開されたため、管理者はほとんどの作業を自分で行いました：アプリケーションを受け入れ、計算能力を割り当て、特定のサーバーが現在ロードされている量を手動で追跡しました。 多くの場合、特定のIronサーバーに仮想マシンが非常にロードされているため、手動で最適化し、サーバーからサーバーに仮想マシンを転送する必要がありました。 これはすべて、プロジェクトチームの作業をひどく妨害しました。 彼らは特定の力を注文しましたが、それを得ることができませんでした。



結論：仮想化は良いが、手動制御は悪い。 「半指天井」の原則に基づいて採用されたエンジニアの決定によれば、1台または別のサーバーの負荷が他のサーバーよりも低かった。 その上にある仮想マシンが現在実行されていないという理由だけで。 しかし、このプロジェクトがホットフェーズに入り、これらすべての仮想マシンが起動することを予測することはほとんど不可能でした。 プロジェクト計画を改善できる非常にインテリジェントなエンジニアが必要でした。 そして、それらが同時に何百人もいるとき、これは別のタスクです。 この方法で作業するのは非常に困難であり、フックまたは詐欺によって実際のハードウェアを注文したため、多くは仮想マシンの注文を停止しました。 ただし、プロジェクトに鉄のサーバーを吊るすことの方がはるかに高価であることは明らかです。 場合によっては、桁違いではありません。



したがって、もちろん、管理プラットフォームを配置する機会が現れたときに、それを配置します。 彼らがHPを選んだのは、一部にはシステムの操作経験が豊富だったからです。一部には、当時BMCしかなかった「クラウド」の管理に関してHPの真の競合他社がいたからです。 しかし、開発タスクでは、ユーザーが独自のスタンドパラメーターを選択できるように、HPは管理の柔軟性の点でより適していました。 このすべてを自動化すると、仮想マシンがどこで回転しているかを考える必要がなくなり、必要なパフォーマンスレベルを維持するために、仮想マシン自体が1つの計算能力から別の計算能力に移行されます。 特定の必要なパワークォンタムを超えると、それ自体がますます追加されます。 現在、当社のエンジニアは実質的に鉄サーバーを注文していません。



次に、パブリック「クラウド」へのコネクタを管理するこのシステムを完成させました（Amazonおよび私たち自身のパブリック「クラウド」に対しても選択を台無しにしました）。インターネットアクセスがある場所で結果のソリューションを顧客に示すことができます。 たとえば、CAには、デフォルトでパブリック「クラウド」への直接コネクタがあります。 そのため、場合によっては、ファイナライズを気にしたくない場合は、CAを選択できます。



現在、プライベートな「クラウド」には約1000のスタンドがあり、それらはすべてアクティブ化されているわけではありませんが、平均して5回ごとに常に機能しています。 サーバーは非常に異なっており、「クラウド」の観点からは、IBM BladeとHP Bladeのどちらを使用できるかはそれほど重要ではありません。 「マトリックス」に接続することにより、彼は単に海の別のドロップになります。 内部請求システムのおかげで、特定のスタンドのコストは自動的に特定のプロジェクトに当てられるようになりました。 ペニーまで。 これ以上でもそれ以下でもありません。 さらに、ダウンタイムを考えると、つまり、仮想マシンをしばらく停止した場合、料金は発生しません。 もちろん、天と地は、以前と比較して、魔法のような完全に不透明な方法で研究室のすべての費用が部門、方向、グループに分配されていました。



しかし、先に進みましょう。

スケーリング

通常、非常に簡単に行われます。 定義済みのブロックがあります：自動化はインフラストラクチャレベルをカバーします。 ほとんどの場合、すべては、何に備えてラックに追加のユニットを設置するかによって決定されます。 タスクがそれほど大きくない場合は、サーバー、ストレージシステム、まとめての追加配信が考えられます。 大規模な場合-ファームの展​​開とそれらの間の通信の組織。 したがって、「来年、ユーザーを30％増やす予定です。ここにコストがあります」などの予測を立てるのは簡単です。

建築

高いレベルでは、多くのメーカーで同じことが一般的です。 次に、商用とオープンソースの両方の実装から特定のソリューションが選択され、詳細、ハードウェアなどについて対話が行われます。 どのメーカーのどのコンポーネントがどの機能を実行するかを決定します。



管理については次のとおりです。





BMCクラウドライフサイクル管理プラットフォームのアーキテクチャ例





IBM CLOUD SERVICE PROVIDER PLATFORM PLATFORM（CSP2）のアーキテクチャ例





クラウドプラットフォームのCA Automation Suiteのアーキテクチャ例





プライベート「クラウド」の共通インフラストラクチャコンポーネントを使用したスキーム

ハイブリッドおよびパブリック「クラウド」への移行

プライベートな「クラウド」では、顧客はしばしばサービスの提供を磨きます。 その後、データの機密性を理解すると、パートナークラウド、ハイブリッド、またはパブリッククラウドを安全に使用できます。 たとえば、銀行は重要なデータを独自の安全な環境で処理します。スキル、新しいセキュリティ手順、自動化などを習得します。 新しいリソースが必要であることが明らかになり、一般にそれらの使用が情報セキュリティに対する脅威ではない場合、パブリッククラウドのリソースが使用されます。これは、ファームを自分の内部に展開するよりも単純です。

ご質問

それだけです コメントまたはメールIShumovskiy@croc.ruでご質問にお答えします。 必要な場合は、状況に応じた実装オプションのおおよその計算を送信できます。



より実用的な詳細が必要な場合は、明日10:30から15:30まで、オフィスでセミナーが開催されます。 「クラウド」および「クラウド」ITSMのアーキテクチャ、「サービスデスク」サービスをプライベート「クラウド」に移行する経験、事前請求およびリソースアカウンティングソリューション、プライベート「クラウド」の管理方法について詳しく説明します。このためのソリューションがあり、この場合またはその場合に選択する方がよいものがあります。一般に、プライベート「クラウド」の展開に必要なハードウェアおよびシステムソリューション、「クラウド」データの保護、その他多くの有用なものです。 また、Forresterの特別ゲスト、Lauren I. Nelsonがいます。ITインフラストラクチャおよび運用の分野の専門家と協力するアナリストです。 また、いくつかの秘密を共有することを約束します。 一般的に、これは有用な成果です。 こちらから無料の会員登録をしてください 。