クラウドプロバイダーを選択するための実用的なヒント

クラウドプロバイダーの選択は難しい作業です。 この投稿では、彼女にアプローチする方法、まず何を探すべきか、キャッチが隠されている可能性のある場所、プロバイダーとのコミュニケーションを一般的に構築する方法を説明します。 以下は、イベントの開発、クラウドへのITインフラストラクチャ全体の移行の最も複雑で複雑なシナリオの説明です。 ITインフラストラクチャの重要な部分をクラウドに移行してみましょう。クラウドにアクセスできないと、数時間でも企業のビジネスに重大な損害を与える可能性があります。

メモ

ホスティングプロバイダーを除外する方法

1. 原則としてサーバー仮想化が使用されていますか？
2. ストレージ仮想化またはネットワーク仮想化が使用されていますか？ これらはオプションの要件ですが、クラウドプロバイダーの技術レベルを示します。
3. サービスを管理する方法は？ セルフサービスポータルはありますか？ 自分で新しいサーバーを起動して、すでに実行されているサーバーのパフォーマンスを制御することは可能ですか？ ドライブを追加し、内部アドレス指定を構成し、ルーティングを管理できますか？ 自分でバックアップスケジュールを設定し、データ回復タスクを実行できますか？ 等
4. リソースはどのように考慮されますか？ 自動請求（1秒ごと、1時間ごと）がありますか？ または、すべてが手で数えられますか？

遊び場

1. データセンターはどこにありますか：海外ですか、それともロシア連邦ですか？ オフィスと2番目のデータセンターがあれば、どれくらい離れていますか？ 遅れ？
2. データセンターの所有者は誰ですか？ 見に来てもいいですか？
3. 彼は認定されていますか？ 以前、このサイトでの事故は何でしたか？
4. どの通信プロバイダーがサイトに存在しますか？
5. 「クラウド」に接続するにはどうすればよいですか？

クラウドサービス

1. vCPU（仮想コア）とは何ですか？ プロセッサの物理コア全体、またはその四半期など、何が同等ですか？
2. どのディスクリソースが使用されていますか？ ローカルまたはSAN接続ですか？
3. インターネットへのチャンネルはどのように予約されていますか？
4. 「クラウド」の標準機能では不十分な場合はどうなりますか？ たとえば、専用のネットワーク機器や非x64アーキテクチャのマシンを「クラウド」などに接続することは可能ですか？
5. ハイブリッドモードは利用できますか？ この場合、統合はどのように行われますか？
6. バックアップサービスはありますか？
7. ISツールはデータベースでどのように利用できますか。どのツールを別途注文する必要がありますか？
8. HA（高可用性）またはDR（災害復旧）ソリューションを構築する必要がある場合、2つのデータセンター間でホステッドITサービスの部分を分離することは可能ですか？ プロバイダーは、そのようなソリューションを構築するための2番目のクラウドを持っていますか？

サポート

1. サポートは24時間年中無休で迅速に対応しますか？
2. 言語-ロシア語と英語？
3. 本当に必要な場合、SLAをどの程度超えることができますか？ （原則として、西側-側への一歩ではありません）。
4. リソースとバランスを監視するためにサポートに連絡する必要がありますか、それともすべてのデータはセルフサービスポータルから利用できますか？
5. デモモードはありますか？ 「戦闘」とはどの程度違いますか？

注：多くの質問は、その規模ではなく、Webサイトの「クラウド」への転送の一部として特に実用的ではありません。 もちろん、サイトは異なりますが。

1.サイトの選択

クラウドプロバイダーの選択は、データセンターの物理サイトから始まります。 プロバイダーのデータセンターが「なる」と、「クラウド」もオフになります。つまり、そのクラウドで動作するすべてのITシステムにアクセスできなくなります。 多くは、クラウドプラットフォームのアクセシビリティを確保するための内部手段についてプロバイダーに尋ねています。 これは正しいですが、十分ではありません。



データセンターの場所を調べる

ロシアですか、それとも海外ですか？ これは重要です。なぜなら、法律の下ではある種のデータをロシア連邦外に持ち出すことができないからです。 逆もまた当てはまります。一部の企業は、チェックから自分自身を少なくとも部分的に保護するために、西部のデータセンターのデータの一部を隠そうとしています。 さらに、ITインフラストラクチャ全体を「クラウド」に移行する必要がある場合、遅延の問題が関係します。 システムの一部をアイルランドのどこかにあるパブリック「クラウド」に配置するとします。 通信チャネルの既存の遅延により、システムで快適に作業できるようになりますか？ この瞬間は多くのことをやめ、ローカルデータセンターを優先して選択が行われます。

例：CROCでは、3つの独自のデータセンターがすべてモスクワにあり、単一の光リングで結合されています。

データセンターの所有者は誰ですか？

データセンターがプロバイダーによって所有されているのか、プロバイダーがパートナーからデータセンターを借りているのかにも注意する価値があります。 レンタルサイトには何の問題もありません。 パートナー企業は、あらゆる状況で迅速かつスムーズに行動できる有能なスペシャリストを雇用する可能性があります。 しかし、それでも、サイトをレンタルする場合、データセンターの会社所有者のエンジニアとして、送信してから作業を開始するまでのアプリケーションのパスは少し長くかかります。 この場合、クラウドプロバイダーは転送リンクとして機能し、作業スキームの柔軟性と運用性は低下します。



サイトを選択するときは、データセンターにアクセスする機会にも注意を払う必要があります。 データセンターが所有されていて、プロバイダーに非表示にするものがない場合は、ツアーに招待されます。 遠足ができない場合、これはいくつかの疑問を提起します。 失敗とは、サイトがレンタルされており、クラウドプロバイダーがツアーについてデータセンターの所有者に同意できなかったか、サイトで何かが間違っていたことを意味します。 もちろん、他の理由もあるかもしれませんが、データセンターの信頼性に関する疑問はまだ生じています。

すべてのCROCデータセンターが所有されています。 データセンターへの遠足は、グループと個人の両方で定期的に行われます。

サイトは認定されていますか？

データセンターの認定市場のリーダーはUptime Instituteです。 この会社は、データセンターコンポーネントの信頼性要件の最新リストを保持しています。 その要件と推奨事項は、実際のデータセンターの障害を考慮して、世界中のデータセンターを運用した実際の経験に基づいています。



稼働時間の認証は、紙のプロジェクトの認証と完成したサイトの認証の2つの段階で構成されます。 サイトの認定には最大3週間かかります。 稼働時間のスペシャリストが来て、サイト上のすべての技術ソリューションと紙上の設計ソリューションのコンプライアンスを個人的にチェックします。 その結果、適合証明書が発行されます。 現在ロシアには5つの認定データセンターがあり、そのうちの1つは当社のものです。



Uptime Instituteによる認証に代わるものがあります-TIA-942標準への準拠の検証。 これは、データセンターを作成するための推奨事項を記載したアメリカの標準です。 この標準の欠点は、長い間更新されておらず、多くの要件の点でUptimeに遅れていることです。 また、大きなマイナス点は、この標準が本質的に勧告であり、少なくともロシアでは、データセンターがその準拠をチェックしていないことです。 クラウドプロバイダーの正直な言葉を信じなければなりません。



一般的に、データセンター認証の問題は、絶え間ない議論の源です。 多くの人は、データセンターサービスのプロバイダーを信じていないため、認証は役に立たず、認証機関（Uptime Institute）をまだ信頼していないと言います。 それどころか、多くは外部監査人との共同作業のみを信頼しています。



この問題に建設的にアプローチし、物事を冷静に見ると、セトリスパリバスは、認定されたデータセンターに自信を持ちます。 そのようなオブジェクトで事故が発生すると、プロバイダーだけでなく外部監査人の評判も低下します。また、アップタイムの評判は高くつきます。 認定されていないサイトでは、専門家でない場合に確認するのが非常に難しい微妙な違いがたくさんあります。 認定サイトは外部のスペシャリストによって検証されており、問題の少ない技術的なソリューションが含まれています。

認定されたデータセンターと認定されていないデータセンターを区別できる、一見小さなディテールの例を挙げましょう。 彼女は、顧客がチェックすることすらしないもののカテゴリーに属しています。 データセンターには空調システムがあります。 これは、データセンターにある室内ユニット（ファンコイル）と、屋根に設置された外部冷却ユニット（チラーと冷却塔）で構成されています。 空調システムは、N + 1スキームに従って予約されています。 空調ユニットに障害が発生しても、データセンターは停止しません。 問題は、故障した空調ユニットを交換するために、クーラントの供給を遮断する必要があるという事実にあります。 また、供給が1つだけで予約されていない場合、すべてのエアコンがオフになり、データセンターが停止します。 これは、システムのある「クラウド」が「上昇する」場所です。

別の例を次に示します。数年前、モスクワでハリケーンがありました。 隣接する建物の屋根から風で金属板が吹き飛ばされ、データセンターの屋根に落ちました。 リストは、建物の屋根にある屋外空調ユニットへのクーラントの供給を中断しました。 誰がそのようなシナリオを想像できたでしょうか？ 屋根の上に設置され、フェンスで囲まれた冷却システムで何かが起こると誰が考えたでしょうか？ その結果、クーラントが漏れ、データセンターが停止し、すべての顧客システムがオフになりました。

サイトがUptime Institute TIER III規格に従って認証および構築された場合、バックアップ冷却剤の供給に切り替えて、パイプラインの損傷部分を分離することが可能です。 したがって、深刻なタスクを転送するためにクラウドプロバイダーを選択する場合、データセンターレベルまで、多くの側面に注意を払う必要があります。 クラウドサービスは「入れ子」であり、データセンターがその中心であるためです。



誰かが、どのようなデータセンタープロバイダーが存在するかは問題ではなく、明確なSLAがあり、その中で作業していることに気付くかもしれません。 そして、私たちはサイトを運転して見たくないので、「クラウド」が必要です。 しかし、データセンターとそれを使用するすべてのシステムが「立ち上がる」とすれば、罰金が経営陣にとって最後の関心事になると考える人はほとんどいません。 そして何よりもまず、会社の仕事が盛り上がったという事実のためにスキャンダルがあり、何かを緊急に行う必要があります。

CROCは現在3つのサイトを所有しています。

•Volochaevskaya 1（70ラック+クラウド1）TIER 3 TIA-942

•Volochaevskaya 2（110ラック）TIER 3 TIA-942

•コンプレッサー（800ラック+クラウド2）TIER 3 Uptime Institute

認証の原則については、 こちらをご覧ください 。 こちらの UIによるサイト認証を確認してください。



外の世界とのつながり

クラウドプロバイダーには、特に外部からデータセンターと「クラウド」に接続する方法を常に尋ねる必要があります。 デフォルトのインターネットアクセスオプションは何ですか？ また、ポイントツーポイントチャネルを使用して「クラウド」に接続できますか？



独自のチャネルで「クラウド」に接続できる場合は、通信サービスが一部のサイトで独占されているため、データセンターに存在する通信プロバイダーを明確に尋ねる必要があります。 たとえば、プロバイダーXのみがあり、それだけです。プロバイダーを連れて行くことはできません。

現在、CROCデータセンターネットワークには13の通信プロバイダーがあり、お客様に便利なプロバイダーを受け入れる準備ができています。

2.クラウドプラットフォーム

CPUリソース-なぜお金を払うのですか？

物理的なサイトを選択する際に何を探すべきかを考えました。 それでは、クラウドプラットフォーム自体を選択する際に尋ねるべき質問のリストに移りましょう。 まず、コンピューティングリソースの割り当てと販売の原則、つまりプロセッサ容量から始めましょう。 市場でプロセッサ容量を販売するには、いくつかの方法があります。

• 「共有」リソースの販売。 現在無料のものはすべて、サーバーに占有させることができます。
• 保証されたリソース割り当て。

原則として、最初のオプションは美しいマーケティングラッパーで提供されます。 コンピューティングリソースの割り当ての下限と上限を選択できます。 下限は保証付きで割り当てられ、下限と上限の間のリソースはオンデマンドで割り当てられ、使用時に支払われます。 アプローチは美しいです。 しかし、ニュアンスがあります。 仮想サーバーで利用可能なすべてのリソースを緊急に必要とする場合、物理サーバー上の隣人がそれらを使用せず、それらを割り当てることができるという事実からはほど遠いです。

リソースを提供する2番目のオプションは、支払いに関しては柔軟性が低くなりますが、リソースの割り当ておよびシステムの運用に関してはより安定しています。

これまたはそのアプローチを使用すると、特定の状況で有利に使用できる多くの利点と欠点があります。 どちらのアプローチにも生命に対する権利があります。

特に、CROCは保証されたリソースを提供します。

vCPUとは何ですか？

クラウドプロバイダーは、vCPUでサーバーの処理能力を測定します。 それが何であるか見てみましょう。 ここに私が出会ったvCPUのパワーを計算するための可能なオプションがあります：

• プロセッサの物理コアの0.4-1 GHz周波数
• プロセッサの物理コアの1/3または1/4
• 1つの物理プロセッサコア

これは、プロバイダーに計算方法を尋ねることで、依然として何らかの方法で整理できます。 しかし、他にも落とし穴があります。 プロセッサコアの処理能力は、2007年から3.5倍に増加しています。 これは、Amazonで利用可能なタイプの仮想サーバーで確認できます。 2007年、Amazonはクラウドサービスの提供を開始し、そのための機器が購入されました。 その後、Intel Celeronプロセッサが使用されました。 それらのパフォーマンスを測定し、基準として採用しました。 この標準はECU（Elastic compute unit）と名付けられました。 Amazonで仮想サーバーを注文できるようになりました。その物理コアの能力は3.5 ECUに相当します。 このことから、過去6〜7年間のプロセッサコアの成長は3.5倍になったと結論付けることができます。



そして今、vCPUの下のクラウドプロバイダーは物理コアではなく、その一部を暗示しているかもしれませんが、古いハードウェアも使用できることを考慮します。 これは、異なるプロバイダーのvCPUが20〜30倍異なる可能性があることを意味します。 常にvCPUとは何か、vCPUと物理コアとの関係、および一般的に使用されるプロセッサを尋ねる必要があります。

特に、CROCはAmazonプロセッサの電力を測定する方法論に付属しており、vCPUの電力は3.23 ECUで、Intel Xeon x5650プロセッサ2.6 GHzの物理コアの電力に対応しています。

ディスクリソース

クラウドプロバイダーを選択するときは、仮想マシンに提供されるディスクリソースに注意する必要があります。 まず、データウェアハウスが物理的にどのように見えるかを尋ねる価値があります。

• ボードサーバー上のローカルドライブ
• 直接接続されたディスクシェルフ
• SAN接続ストレージ

最初のオプションと2番目のオプションには、サーバーに障害が発生した場合のデータ損失または長いアクセス不能が伴います。 特に、Amazonはボーナスとしてローカルドライブ上の仮想マシンのディスクスペースを顧客に提供します。 サーバー障害には、すべてのデータの損失が伴います。 追加料金で、外部ストレージシステム（EBS）に追加のディスク領域をレンタルできます。

クラウドプラットフォームのアーキテクチャの形成段階にあるCROCは、仮想マシンデータの保存にローカルサーバーディスクの使用を拒否しました。 すべてのサーバードライブは、SAN接続のストレージシステムに保存されます。 物理サーバーに障害が発生すると、「クラウド」の残存部分で仮想サーバーが自動的に再起動されます。

ディスクリソースを検討する際の2番目の重要なポイントは、IOPS、データの読み取りまたは書き込みの速度に関して保証されたSLAです。 プロバイダーは特定のストレージパフォーマンスを保証していますか？ CROCクラウドプラットフォームディスクは、保証されたSLAなしで提供されます。 同社は、既存のストレージシステムをタイムリーに拡張し、新しいストレージシステムを追加するためにあらゆる努力を払い、常にパフォーマンスを監視しています。 顧客がクラウドの近くでIOPSを保証する必要がある場合、これらの要件を満たす物理ストレージシステムをいつでもデータセンターに配置できます。 実際に私たちの大口顧客はまさにそれをします。 幸いなことに、物理的な機器を受け入れる準備ができている3つのサイトがあります。



「クラウド」に接続する方法は？

クラウドプロバイダーは、デフォルトでインターネット上の仮想サーバーにアクセスするためのサービスを提供します。 もちろん、彼らはさまざまな方法でそれを行います。

まず、この接続が予約されているかどうかを尋ねる必要がありますか？ 異なるプロバイダーが使用されていますか？ 通信チャネルの1つに障害が発生した場合の切り替えはどうですか？

特に、CROCは、インターネットから、自律システムのレベルで自動的に切り替えられるアクティブ/パッシブモードで動作する異なるプロバイダーからの2つの1Gbit通信チャネルへのアクセスを提供します。

2番目の重要な質問は、プロバイダーがインターネットへの通信チャネルの帯域幅を形成できるかどうか、つまり特定の帯域幅を保証できるかどうかです。

CROCはこのサービスを提供しませんが、チャネルの使用率を常に監視し、通信チャネルの容量をタイムリーに拡大しようとします。

大規模なお客様はすべて、便利な通信プロバイダーと連携して、ポイントツーポイント接続を整理します。 これは、インターネット経由で接続するよりも安全な接続方法です。



「クラウド」の標準機能では不十分な場合はどうなりますか？

クラウドプラットフォームは、すべての問題に対する万能薬ではありません。 すべてのITタスクを完全に解決することは不可能です。 クラウドプラットフォームが役に立たない例は次のとおりです。

• 利用可能な仮想サーバーの種類はあなたに適していません。 40の物理コアを持つマシンが必要です。
• AIXまたはHP-UXで実行されている重いデータベースサーバーがあります。 「クラウド」に転送する必要があります。 また、これらはx64アーキテクチャではなく、SPARCおよびEPICのサーバーです。 「クラウド」では、仮想マシンでこのサーバーをホストすることはできません。
• プロバイダーは、ストレージのIOPSを保証しません。 専用のストレージが必要です。
• データ転送にはGOST暗号化を使用する必要があります。 特別な暗号ゲートウェイをインストールする必要があります。
• 専用の通信チャネルを接続し、通信チャネルを切り替えて物理機器を制御する必要があります。

例は長い間リストできます。 クラウドプラットフォームの組み込み機能をまだ使用していない場合、いつかは使用できなくなるという事実が残っています。 天井にぶつかったらどうしますか？ この場合、追加の物理機器を「クラウド」に接続してデータセンターに配置できるかどうかをプロバイダーに確認する必要があります。

CROCはそのようなサービスを提供します。 さらに、ほとんどのお客様は私たちから物理的な機器をレンタルし、クラウドで消費しています。 専用の通信チャネルを接続するために最も一般的に使用されるレンタルネットワークルーター。

クラウドとの統合。 ハイブリッドモード

ほとんどの場合、「クラウド」への移行を検討するときは、一度にそれを行うことはありません。 ローカルサイトと「クラウド」の両方に住んでいる場合、長い移行プロセスがあります。 一部の企業では、このプロセスが1年続き、完了しないことがあります。

この場合、プロバイダーは、ローカルITインフラストラクチャをクラウドと統合するためのメカニズムについて質問することが重要です。

パブリックな「クラウド」の使用を検討する場合、デフォルトでは「クラウド」側のネットワーク設定の管理は実質的にありません。

• 内部アドレス指定を管理することはできません。 彼らができれば、崩壊が起こるでしょう。
• ルーティングを制御することはできません。
• ロシアのプロバイダーの大半を考慮すると、「クラウド」内のネットワークはVLAN上に構築されます。 通常、1人の顧客= 1つのVLAN。 すべての車は同じネットワーク上に存在します。 誰もが追加のVLANを作成できるわけではありません。

クラウド内でネットワークを管理することは、現場で利用できる柔軟性と利便性のレベルからはほど遠いものです。 ネットワーク統合ツールを忘れる価値があります。 強みとして、サイト間にVPNトンネルを構築する可能性があります。

幸いなことに、ローカルサイトと同じように「クラウド」でネットワークを操作するための同じ便利なメカニズムを実装するための技術的なソリューションがあります。

CROCは、以前の投稿で説明した ネットワーク仮想化ソフトウェアを使用します 。 このソフトウェアにより、顧客はセルフサービスポータルを通じて独立して管理できます。

• クラウドネットワークの内部アドレス指定
• 必要な数の追加ネットワークを作成します
• ファイアウォールを介したそれらの間のアクセスを制御する
• 静的または動的ルーティングを構成する
• ローカル物理ネットワーク機器の構成をアップロードして、VPNを構成します

したがって、この機能を使用すると、サイト間で水平L2ネットワークを構築するまで、「クラウド」で内部アドレス指定を便利な方法で構成できます。 独自のVPNを構成し、ルートを処方できます。 実際、サイトと同じように「クラウド」でネットワーク設定を管理できます。 「クラウド」は、実際には顧客のサイトのローカルインフラストラクチャの論理的な継続となります。 ITシステムは物理的に異なる場所に配置されるという事実にもかかわらず、互いに完全に透過的に動作できます。



「クラウド」に配信されるシステムの一部をローカルシステムと緊密に統合する場合は、プロバイダーにネットワーク管理機能について問い合わせる必要があります。



データのバックアップ

データのバックアップは、クラウドプラットフォームの基本的なサービスの1つです。 しかし、多くの人は彼を忘れています。 まず、そのようなサービスが原則として利用可能かどうかをプロバイダーに尋ねる必要があります。 まだ残っている場合は、追加の質問をすることができます。 商用製品またはオープンソースを使用しましたか？ フリーソフトウェアを使用する場合は、ベンダーではなくプロバイダーがこのソリューションのサポートに従事しているリスクをすぐに判断する価値があります。



したがって、2番目のリスク。 ベンダーは、アプリケーションソフトウェアの一貫したバックアップに必要なすべてのエージェントを使用して、バックアップソフトウェアを完成させます。 Opensourceバックアップソリューションを使用してSAPをバックアップできる可能性はほとんどありません。 このバックアップソリューションの互換性リストについては、常にプロバイダーに問い合わせてください。



保存されているコピー、ディスク、またはテープについて、プロバイダーに確認することが重要です。 テープは安価な媒体ですが、回復しないリスクははるかに高くなります。 さらに、テープを使用した作業は、ディスクメディアを使用した場合よりも遅くなります。 情報がディスクに保存されており、追加サービスとして定期的にコピーを差し押さえられたメディアに書き換える必要がある場合、プロバイダーはこの可能性について問い合わせる必要があります。



そして最後に、重要なポイントはサービスの種類です。 どのように制御できますか？ セルフサービスポータルはありますか？ バックアップスケジュールを自分で管理し、プロバイダーを介さずにデータをバックアップおよび復元できますか？

CROCは、 EMC Avamarハードウェアおよびソフトウェアシステムに基づいたバックアップソリューションを構築しました。 情報は重複排除された形式でディスクに保存されます。 サービス管理は、完全に機能するセルフサービスポータルを通じて実行されます。

情報セキュリティ

この質問は、クラウドプロバイダーにとって最も頻繁に議論され、最も恐ろしいものです。 アクセシビリティツール（機器と通信チャネルの冗長性、個別のデータストレージ、RAID、バックアップ）に関する質問に加えて、組み込みのアクセス制御ツールの構成、および追加の情報セキュリティサービスのリストについて質問する必要があります。



組み込みツールに関しては、Windowsマシンのパスワード保護と、キーを使用したLinuxマシンの保護について質問する価値があります。 新しいマシンを作成しましたが、そのマシンへのアクセスはどのように保護されていますか？ 標準のパスワードを使用して、外部IPアドレスでインターネット全体ですぐに使用可能になりますか？

また、ネットワークアクセス制御について尋ねる価値があります。 もちろん、ビルトインファイアウォールを制御することは可能ですか？



追加サービスに関しては、プロバイダーに（D）DoSからの保護のためのサービスの購入の可能性、および侵入（IDS、IPS）を検出および防止し、ウイルス対策およびスパム対策をレンタルするシステムについて購入者に尋ねる必要があります。



災害復旧または高可用性ソリューションの構築

タスクが非常に重要になる可能性があるため、データセンター間でタスクを予約し、クラスターにコストをかけ、ストレージシステム間のレプリケーションを構成する必要があります。 あなたのプロバイダーはこのイベントの変わり目に準備ができていますか？ または、2番目のプロバイダーを引き付ける必要がありますか？



2番目のプロバイダーを引き付けることは、責任の侵食に悩まされ、おそらく異なるSLA内の2つの技術サポートサービスと連携します。 これは、ITインフラストラクチャのパフォーマンスに悪影響を与える可能性があります。

現在、CROCには、異なるデータセンター（Volochaevskaya-1およびCompressor）に2つのクラウドプラットフォームがあります。 両方のプラットフォームは、単一のセルフサービスポータルを介して管理されます。 これにより、可用性の高い分散ソリューションを構築できます。 まあ、または少なくとも、メインデータに関連するリモートサイトにバックアップを保存するために。

さらに、追加の契約に署名する必要はありません。 顧客にとって、2つのクラウドプラットフォームで作業するプロセスは完全に透過的です。

おわりに

プロバイダーの申請者に質問の全リストを尋ね、それらに対する回答を得ても、そこで止まるべきではありません。 実際に聞こえる内容をすべて確認するには、デモへのアクセスを要求する必要があります。 最後に、タスクでサーバー、ストレージ、ネットワークのパフォーマンスをテストします。 テストは、特定のプロバイダーが適切かどうかの最も顕著な指標になります。 彼は彼の言葉を保証します、彼の約束は現実に対応していますか？



しかし、これだけではありません。 残念ながら、クラウドプラットフォームでの作業の多くの機能はテスト段階では感じられません。 サービスの長期運用中に必然的にいくつかの驚きが浮かび上がります。 これらの驚きは重要ではなく、非常に目立つものであることが判明する可能性があり、その後、このプロバイダーとのさらなる作業の可能性が疑問視されます。



プロバイダーとの通信の最後に、常に別のサービスプロバイダーへの移行の問題について話し合う必要があります。 仮想マシンを目的の形式に変換するなど、データ収集の可能性を見つける必要があります。