しかし、時間のラッシュのため、パートナーが詳細に質問や困難に答えるためにあまりにも多くの時間を残していないので、東魏は、会議の後、より多くの統合された問題のいくつかについて懸念し、問題と解決策で発生した困難のいくつかを構築する過程で分析され、次の内容のこの部分については、彼の照合です：
ここではまず、この構築で使用したNoSQLデータベースMongoDBクラスタのアーキテクチャの概要と、その機能の一部を紹介します。
このクラスタでは、マスター（プライマリ）ノードがあり、書き込み操作を受信するために使用され、残りは副（セカンダリ）ノードであり、それらは同期Oplogを介してマスターノードから来て、データの同期を達成するためにローカルデータに適用され、クラスタノードは、クラスタ間の相互運用性を確保するためにハートビート（ハートビート）検出を持っています。
そのクラスタのマスターノードが利用できなくなると、残りのノードが自動的に選挙によって新しいマスターノードを生成します。これはMongoDBクラスタリングの特徴であるプロセスで、次の図のようになります：
私はあなたに3つのシナリオを示しました：
*** MongoDBクラスタの初期化プロセスです。最初に SpeedyCloud クラウド API をコールしてクラウドホストの作成と MongoDB インスタンスの起動を行い、データベースの状態を確認した後、初期化コードの一部を実行してクラスタ全体の初期化を完了します。
2つ目は、MongoDBクラスタの障害デバイスの交換です。クラスタ内のデバイス障害をシミュレートするために、ホストを手動でシャットダウンし、監視システムの検出により、障害デバイスが自動的に検出され、クラウドホスト作成プロセスが呼び出され、クラスタ内の障害デバイスの自動交換を実現するためにメンバー追加プロセスが呼び出されます。
第三に、クラスタ全体を破棄します。クラスタ全体のライフサイクルが終了すると、SpeedyCloudクラウドAPIを呼び出してクラウドホストのID番号を渡すことで、クラウドホストの自動破棄処理が実現されます。
SpeedyCloudクラウドAPIコール、Puppet構成管理システムの利用、MongoDBクラスタのメンテナンス、Zabbix監視システムの利用です。
クラウドホストに組み込まれたPuppetエージェントを通じて、Puppetマスターと対話し、パスワードの変更や設定ファイルの管理などを実現します。Zabbixエージェントを通じて、監視システムへのデバイスの自動登録や監視データのレポート機能を実現します。同時に、Zabbixサーバのトリガにより、障害ホストの発見、処理スクリプト呼び出しの障害発見を実現します。システムの全体構成を以下に示します：
ここからはQ&Aパートで、ミーティングやその後に皆さんから寄せられた質問にお答えします。#p#
Q&Aコーナー
質問1：
回答：SpeedyCloudの実行システム全体では、デバイスのIPは常にデバイスに追従しており、デバイスが破棄される前に変更されることはないため、新しく生成されたデバイスは新しいIPを有効にすることしかできません。このとき、スクリプトを使用して新しく追加されたIPをHAの設定ファイルであるhaproxy.cfgに書き込み、Puppetの対応するディレクトリに配置する必要があるかもしれません。その後、PuppetエージェントがこのファイルをHa-proxyデバイスに配布し、rebootコマンドを呼び出して新しいデバイスの追加を完了します。
質問2：
A:MongoDBのレプリカセットモデルの利点は、クラスタでは同じデータが複数のノードに保存され、デバイスはイントラネットで接続されているため、マスターノードのデータはクラスタ内のすべてのノードに常に最速で同期されます。システム全体のデータ整合性には影響しません。
質問3：
A: 通話のセキュリティは、これらの手段によって確保されています：
***は、呼び出しでは、ユーザー名とパスワードを提供する必要はありませんが、APIキーを提供することにより、識別を達成するために、このAPIは、アカウントのパスワードのセキュリティを確保するために、暗号化された64ビットの文字列です：
次に、投稿時にシステム時刻を検証する必要があり、時刻の一意性とURLの****を保証する方法として、システム時刻とAPI-KeyをSHA1暗号化する必要があります；
第三に、顧客がAPIを呼び出す場合、HTTPSに基づいて呼び出すことができ、呼び出しのセキュリティをさらに確保することができます。
質問4：
A：APIを通じて作成されたクラウドホスティングは、時間単位で支払う戦略を採用しています。顧客は事前に自分のアカウントにいくつかの金額を充電する必要があり、その後、各時間は、ホストの構成と対応する控除操作の使用に応じて、この時間のホストの使用をカウントし、顧客の残量が控除するのに十分でないことが判明した場合、それは事前に顧客に再充電することを思い出させるメールを送信するために1時間になります。
質問5：
A: Puppet Masterは自動認証という機能をサポートしており、Puppet Masterの設定ファイルに3行の設定を追加する必要があります：
[master]
autosign = true #指明要支持自动认证功能
autosign = /etc/puppet/autosign.conf #指明自动认证的规则保存在哪里
また、/etc/puppet/ディレクトリにautosign.confというファイルを作成し、自動認証のルールを保存したり、*をallに追加したり、ドメイン名を追加したりする必要があります：
質問6：APIを呼び出してクラウドホストを作成する際にbootscripパラメータを渡しているようですが、これは何のためですか？
A: これは実行可能なコマンドです。 このパラメータの中に書かれたコマンドは、/etc/rc.local ファイルに書き込まれます。このファイルの目的は、ブート時にいくつかのコマンドを実行することです。ですから、ブート時に実行したいコマンドをこのスクリプトファイルに書いておけば、システムが起動したときにこれらのスクリプトが実行され、やりたいことができるようになります。#p#
困難と解決策
難易度1：
解決策:実は、Puppetを使ってMongoDBのインストールを実装し始めたのですが、インストールパッケージを大量にダウンロードする必要があるため、毎回時間がかかり、デモ中の時間を保証できないことがわかりました。そこで考えたのが、SpeedyCloudのクラウドプラットフォームでは、カスタムテンプレート機能、つまり、インストール済みのクラウドホストをシステムImageとして利用できる機能をサポートしているので、新しいデバイスを作成する際に、Imageの名前をパラメータとして渡すことで、このImageをテンプレートとしてクラウドホストを生成し、MongoDBがインストールされたデバイスをテンプレートとしてクラウドホストを生成することができます。すでにインストールされている MongoDB デバイスをテンプレートとして使うことで、デモで MongoDB ノードを作成するのに必要な時間を短縮できます。
難易度2：
解決策：この問題の解決策は、主にPuppetを使用することですが、もちろん、主に以下の手順など、いくつかの中間プロセスが必要です：
ステップ***では、デバイス作成用APIを呼び出した後、デバイス詳細表示用APIインタフェースを呼び出して、新規作成したデバイスのIPとホスト名の対応をPuppet Master上のhostsファイルに書き込みます。その内容とパスを以下に示します：
2つ目のステップは、Puppet経由でこの設定ファイルを、新しく作成されたすべてのホストの/etc/puppet/config/hostsという場所に配布することです。Puppetでの設定は以下のようになっており、ご覧のように、このファイルが更新されるとauto_register.pyというスクリプトが起動します。
3つ目のステップは、上のイメージにあるように、新しく作成されたすべてのホストの/etc/puppet/config/ディレクトリにスクリプトauto_register.pyをPuppet定義とともに送信することです。このスクリプトは、前のステップで発行されたホストファイルをシステムの/etc/hostsファイルに追加するために使用されます。スクリプトの内容は以下のとおりです：
難易度3：
解決方法:この機能を実装するには、以下の手順でZabbixサーバ側とZabbixクライアント側の両方を設定する必要があります：
***ステップ1.まず、新しく作成したホストにZabbixエージェントをインストールする必要がありますが、これはVMテンプレート作成時にインストールすることができます。
3つ目のステップはZabbixサーバの自動登録機能の設定です。下図に示すパスからアクション定義エリアに入り、"Create action "をクリックして設定インターフェースに入ります。以上の手順が完了し、Zabbixエージェントを再起動すると、クライアントが監視システムに登録されます：
難易度4：
解決策：ここでは、PuppetのFacterの機能とPuppetのContent Definition Templateの機能を使用します。実際には、いわゆるFacterは、rubyコマンド内のクライアント上で実行され、コマンドを介してホストに関するすべての情報を取得することができますし、Puppetクライアントがリソースを要求するサーバーに、それは情報を取得するためにFacterコマンドを介してされるPuppetサーバーに通知されるので、これらの情報の使用のサーバー側は、いくつかのファイルコンテンツを生成するために、これらの情報を使用します。情報を使用してファイルコンテンツを生成します。次の***イメージは、クライアント側でfunctionコマンドを実行した場合の効果です。2つ目のイメージはPuppet Server側でZabbixエージェントの設定ファイルを定義したもので、rubyファイルが使用されていることがわかります。3つ目のイメージはrubyファイルの内容を示しており、hostname変数が使用されていることがわかります。
難易度5：
解決策：最初の起動のこの部分も問題が発生し、pkill zabbixを呼び出した後、すぐにzabbix_agentdを起動することができないことを発見し、後でpkillを呼び出した後、ps -ef｜grepのzabbix内部でゾンビプロセスの多くが表示されることに気づいたので、これらのゾンビプロセスがリサイクルされた後にのみ、起動することができます、このため、簡単な方法は、pkill zabbixを呼び出すことです、コマンドは、リソースを解放するために15秒待ってから、zabbix_agentdを起動することができます。単純な方法は、pkill zabbixを呼び出してから15秒待ってリソースを解放し、zabbix_agentdを起動することですが、もちろんこの15秒は経験値です。この部分のPuppet Server上での設定は以下の通りです：
