クラウド（クラスター）を数セントでホスティングする方法*
3年前、私は面白い仕事をしていました。 LAMPプラットフォーム用に作成されたサイト間でリソースを動的に分散するために、複数のラックとサーバーを1つの全体に組み合わせたプラットフォームを組み立てる必要がありました。 さらに、サイトのコードへの干渉が最小限に抑えられ、さらに優れているため、通常は存在しません。
同時に、Cisco Content Switchや光ファイバディスクシェルフなどの高価なソリューションは使用できません-十分な予算がありませんでした。
また、もちろん、サーバーの1つに障害が発生した場合、これはプラットフォームの動作に影響を与えてはなりません。
まず、プラットフォームの作成をサブタスクに分割する必要があります。 共有ディスクが利用できないため、データを同期するために何かをする必要があることはすぐにわかります。 さらに、トラフィックのバランスを取り、その上に統計情報を用意する必要があります。 最後に、必要なリソースの提供の自動化もかなり深刻なタスクです。
プラットフォームの編成方法を選択できました。 これらはOpenVZとXENです。 それぞれに長所と短所があります。 OpenVZのオーバーヘッドは小さく、ブロックデバイスではなくファイルで動作しますが、Linuxディストリビューション以外の実行方法はわかりません。 XENを使用すると、Windowsを起動できますが、操作がより難しくなります。 問題を解決するのにより適しているため、OpenVZを使用しましたが、選択を制限する人はいません。
次に、サーバーをVDSの下に、コアごとに1つずつ配置しました。 サーバーが異なるため、各サーバーに2〜16個の仮想マシンのセットがありました。 「平均的な病棟」では、ラックごとに150台の仮想マシンがリリースされました。
次の項目は、オンデマンドでのVDSの迅速な作成と、サーバーの損傷に対する保護です。 ソリューションはシンプルで美しいものでした。
各VDSについて、LVMセクションにファイルの形式で初期イメージが作成されます。 このイメージは、すべてのプラットフォームサーバーに「広がり」ます。 その結果、各サーバー上のすべてのプロジェクトのバックアップ（感情の妄想）があり、「オンデマンド」での新しいVDSの作成は、イメージからスナップショットし、VDSの形式で開始するように簡素化されました（文字通り数秒かかります）。
ファイルの整合性が単純な場合、データベースの同期の状況はさらに悪化しました。 最初から、私は古典的な例を試してみました-マスター-スレーブ、そして古典的な問題に出くわしました：スレーブがマスターに遅れました（はい、そして1つのスレッドに複製してくれてありがとう、ありがとう）。
次のステップはMysql-Proxyでした。 システム管理者として、同様のソリューションは私にとって非常に便利でした。新しいVDSを追加/削除するときは、設定だけを更新する必要があることを忘れてしまいました。 しかし、開発者は自分の意見を持っていました。 特に、MySQL-Proxyが役に立たないLuaを学ぶよりも、INSERT / UPDATE / DELETEクエリを同期するための特定のPHPクラスを記述する方が簡単です。
彼らの仕事の結果は、いわゆるAPIでした。これは、ブロードキャストリクエストで隣人を見つけ、現在の状態に同期し、データベースでのすべての変更について隣人に知らせることができました。
しかし、Luaを調べて、すべてのリクエストがネイバーと同期されたときにネイティブモードの操作を行うことはまだ価値があります。
バランサーはプラットフォームの重要な側面です。 バランシングサーバーがクラッシュした場合、すべての作業は意味をなさないでしょう。
そのため、私はCARPを使用してフェイルセーフバランサーを作成し、OSとしてFreeBSDを、バランサーとしてNginxを選択しました。
はい、高価なNLBはFreeBSDを搭載した2台の弱いマシンに置き換えられました（マーケティング担当者は激怒しています）。
プラットフォームの開始時に、サイトごとに1つのコピーが起動され、プライマリコピーが常に機能することを確認するためにバランサーで監視されていました。
さらに、Awstats統計アナライザーがバランサーにインストールされ、すべてのログを便利な形式で提供しました。最も重要なことは、SNMPを介して各VDSの負荷をポーリングするスクリプトがありました。
思い出すように、各VDSに1つのコアを割り当てたため、負荷平均は1です。これはVDSの通常の負荷になります。 LAが2以上の場合、ランダムサーバーでVDSのコピーを作成し、それをアップストリームのnginxに登録するスクリプトが実行されました。 また、追加のVDSの負荷が1未満になったときに、すべてが削除されました。
サーバーとCARPプロトコルをサポートするスイッチを備えたラックを使用する場合、クラウドホスティングを作成するには以下が必要です。
* 4個のゼロのある量で、ラックを満たすのに十分です。 1つのラックの価格が6つのゼロの合計であるブランドのソリューションと比較すると、これは実際には2つのコペックです。
同時に、Cisco Content Switchや光ファイバディスクシェルフなどの高価なソリューションは使用できません-十分な予算がありませんでした。
また、もちろん、サーバーの1つに障害が発生した場合、これはプラットフォームの動作に影響を与えてはなりません。
cの発明の目標
まず、プラットフォームの作成をサブタスクに分割する必要があります。 共有ディスクが利用できないため、データを同期するために何かをする必要があることはすぐにわかります。 さらに、トラフィックのバランスを取り、その上に統計情報を用意する必要があります。 最後に、必要なリソースの提供の自動化もかなり深刻なタスクです。
最初から始めましょう、KOを一緒に連れて行きましょう
プラットフォームの編成方法を選択できました。 これらはOpenVZとXENです。 それぞれに長所と短所があります。 OpenVZのオーバーヘッドは小さく、ブロックデバイスではなくファイルで動作しますが、Linuxディストリビューション以外の実行方法はわかりません。 XENを使用すると、Windowsを起動できますが、操作がより難しくなります。 問題を解決するのにより適しているため、OpenVZを使用しましたが、選択を制限する人はいません。
次に、サーバーをVDSの下に、コアごとに1つずつ配置しました。 サーバーが異なるため、各サーバーに2〜16個の仮想マシンのセットがありました。 「平均的な病棟」では、ラックごとに150台の仮想マシンがリリースされました。
データを同期する方法
次の項目は、オンデマンドでのVDSの迅速な作成と、サーバーの損傷に対する保護です。 ソリューションはシンプルで美しいものでした。
各VDSについて、LVMセクションにファイルの形式で初期イメージが作成されます。 このイメージは、すべてのプラットフォームサーバーに「広がり」ます。 その結果、各サーバー上のすべてのプロジェクトのバックアップ（感情の妄想）があり、「オンデマンド」での新しいVDSの作成は、イメージからスナップショットし、VDSの形式で開始するように簡素化されました（文字通り数秒かかります）。
ベースとAPI
ファイルの整合性が単純な場合、データベースの同期の状況はさらに悪化しました。 最初から、私は古典的な例を試してみました-マスター-スレーブ、そして古典的な問題に出くわしました：スレーブがマスターに遅れました（はい、そして1つのスレッドに複製してくれてありがとう、ありがとう）。
次のステップはMysql-Proxyでした。 システム管理者として、同様のソリューションは私にとって非常に便利でした。新しいVDSを追加/削除するときは、設定だけを更新する必要があることを忘れてしまいました。 しかし、開発者は自分の意見を持っていました。 特に、MySQL-Proxyが役に立たないLuaを学ぶよりも、INSERT / UPDATE / DELETEクエリを同期するための特定のPHPクラスを記述する方が簡単です。
彼らの仕事の結果は、いわゆるAPIでした。これは、ブロードキャストリクエストで隣人を見つけ、現在の状態に同期し、データベースでのすべての変更について隣人に知らせることができました。
しかし、Luaを調べて、すべてのリクエストがネイバーと同期されたときにネイティブモードの操作を行うことはまだ価値があります。
FreeBSDへの栄光
バランサーはプラットフォームの重要な側面です。 バランシングサーバーがクラッシュした場合、すべての作業は意味をなさないでしょう。
そのため、私はCARPを使用してフェイルセーフバランサーを作成し、OSとしてFreeBSDを、バランサーとしてNginxを選択しました。
はい、高価なNLBはFreeBSDを搭載した2台の弱いマシンに置き換えられました（マーケティング担当者は激怒しています）。
そして最も重要なことは、それがどのように機能したか
プラットフォームの開始時に、サイトごとに1つのコピーが起動され、プライマリコピーが常に機能することを確認するためにバランサーで監視されていました。
さらに、Awstats統計アナライザーがバランサーにインストールされ、すべてのログを便利な形式で提供しました。最も重要なことは、SNMPを介して各VDSの負荷をポーリングするスクリプトがありました。
思い出すように、各VDSに1つのコアを割り当てたため、負荷平均は1です。これはVDSの通常の負荷になります。 LAが2以上の場合、ランダムサーバーでVDSのコピーを作成し、それをアップストリームのnginxに登録するスクリプトが実行されました。 また、追加のVDSの負荷が1未満になったときに、すべてが削除されました。
まとめます
サーバーとCARPプロトコルをサポートするスイッチを備えたラックを使用する場合、クラウドホスティングを作成するには以下が必要です。
- Luaを探索し、Mysql-Proxyを介して透過的な同期を構成する
- VDSとトラフィックの追加コピーを考慮した請求書のねじ込み
- VDSを管理するためのWebインターフェイスを作成する
* 4個のゼロのある量で、ラックを満たすのに十分です。 1つのラックの価格が6つのゼロの合計であるブランドのソリューションと比較すると、これは実際には2つのコペックです。
All Articles