AWSアマゾンクラウド構成イントラネット仮想IP(Virtual IP)
2368 ワード
我々は,KeepAliveDを用いたテスト環境で,イントラネットにおけるMysql,Redis,MongoDbの高可用性を実現した.テスト環境のシナリオをアマゾンクラウドに導入すると、アマゾンクラウド環境のいくつかの特性のため、多くの問題が明らかになります.
シナリオの説明:
両方のリソースサーバにMysql、Redis、MongoDbが配備されており、両方のサーバのすべてのサービスがリアルタイムでデータを同期します.各サービスのKeepAliveDは、IP詐欺の方法でブロードキャストAPRパッケージを使用して、対外的なIPを仮想化します.
KeepAliveDは、この2つのサーバの3つのサーバの健康状態を定期的にチェックし、VRRPプロトコルを介して監視します.いずれかのサービスに障害が発生すると、KeepAliveDはARPパッケージをブロードキャストし、この障害のあるサーバはこの仮想IPを持っていないが、もう一つの健康なリソースサーバがこの仮想IPの真の帰属であることを伝えます.これにより、障害サービスに送信された要求はすべて別のリソースサーバに送信されます.
第一.アマゾンクラウドはKeepAliveDのマルチキャストモードをサポートしていません.マスタ間のVRRPパッケージは互いに通じない.
解決方法:KeepAliveDをユニキャストモードに切り替え、配置中にユニキャストマシンのIPを追加すればよい:
さらに、
私たちは多くの方法を試みて失敗し、最終的にメカニズムと勇敢さで解決策を見つけた.以下は簡単な手順と考え方です.
1.2台のサーバーのネットカードの上でこの3つの仮想IPをすべて配合します:
この構成はベース構成です.つまり、IPがこのサーバを指している場合、このサーバ上のNICは自分がこのIPを持っているとは思えない.
2.2台のサーバにアマゾンクラウド独自のクライアントツール(awscli)をインストールする
3.2台のサーバにawscliを登録する.具体的な手順は詳しく説明しない.aws console/service/IAMにアカウントを作成し、システム管理者のグループを作成し、このアカウントをグループに追加する.この過程でAccess Key IDとSecret Access Keyが得られる.サーバ上でawscli configureを実行し、さっきの2つのパラメータを入力し、regionで登録を完了します.regionとは、私たちが買ったシンガポールの機械室のサーバーのように、あなたのサーバーがあるエリアを指します.regionはap-southeast-1に記入します.
4.KeepAliveDがMaster権限を取得したと判断した場合、awscliコマンドを呼び出してVirtual IPを実際に本サーバに向ける.この論理は本文章の核心論理である.アマゾンクラウドではARPのブロードキャストは許可されていませんが、コマンドラインでNIC(ENI)のSecondary-private-ip-addressを指定できます.このコマンドの具体的な形式は次のとおりです.
aws ec2 assign-private-ip-addresses --network-interface-id $ENI --private-ip-addresses $VIP --allow-reassignment
上記の式では、ENIはNICのインスタンスId、ENIはNICのインスタンスId、ENIはNICのインスタンスId、VIPは仮想IPを指す.このコマンドが実行されると、アマゾンクラウドのネットワーク環境では、この仮想IPがこのコマンドを実行したマシンを指し、IP切り替えが完了します.
次はKeepAliveDに関する構成です.
テストにより、以上の方法でアマゾンクラウド(AWS)でイントラネットリソースサーバ(データベース、キャッシュサーバなど)の高可用性を実現することができます.
参照ドキュメント:http://fredlong.iteye.com/blog/2233236
シナリオの説明:
両方のリソースサーバにMysql、Redis、MongoDbが配備されており、両方のサーバのすべてのサービスがリアルタイムでデータを同期します.各サービスのKeepAliveDは、IP詐欺の方法でブロードキャストAPRパッケージを使用して、対外的なIPを仮想化します.
Mysql：172.*.*.201:3306
Redis：172.*.*.202:6379
MongoDb：172.*.*.203:27017
KeepAliveDは、この2つのサーバの3つのサーバの健康状態を定期的にチェックし、VRRPプロトコルを介して監視します.いずれかのサービスに障害が発生すると、KeepAliveDはARPパッケージをブロードキャストし、この障害のあるサーバはこの仮想IPを持っていないが、もう一つの健康なリソースサーバがこの仮想IPの真の帰属であることを伝えます.これにより、障害サービスに送信された要求はすべて別のリソースサーバに送信されます.
第一.アマゾンクラウドはKeepAliveDのマルチキャストモードをサポートしていません.マスタ間のVRRPパッケージは互いに通じない.
解決方法:KeepAliveDをユニキャストモードに切り替え、配置中にユニキャストマシンのIPを追加すればよい:
さらに、
VRRP TCP UDP ， “All traffice” オプションは、ファイアウォールによる通信の問題を防止するために使用されます.私たちは多くの方法を試みて失敗し、最終的にメカニズムと勇敢さで解決策を見つけた.以下は簡単な手順と考え方です.
1.2台のサーバーのネットカードの上でこの3つの仮想IPをすべて配合します:
ifconfig eth0:1 172.*.*.201 netmask 255.255.240.0
ifconfig eth0:2 172.*.*.202 netmask 255.255.240.0
ifconfig eth0:3 172.*.*.203 netmask 255.255.240.0
この構成はベース構成です.つまり、IPがこのサーバを指している場合、このサーバ上のNICは自分がこのIPを持っているとは思えない.
2.2台のサーバにアマゾンクラウド独自のクライアントツール(awscli)をインストールする
easy_install pip
pip install awscli
3.2台のサーバにawscliを登録する.具体的な手順は詳しく説明しない.aws console/service/IAMにアカウントを作成し、システム管理者のグループを作成し、このアカウントをグループに追加する.この過程でAccess Key IDとSecret Access Keyが得られる.サーバ上でawscli configureを実行し、さっきの2つのパラメータを入力し、regionで登録を完了します.regionとは、私たちが買ったシンガポールの機械室のサーバーのように、あなたのサーバーがあるエリアを指します.regionはap-southeast-1に記入します.
4.KeepAliveDがMaster権限を取得したと判断した場合、awscliコマンドを呼び出してVirtual IPを実際に本サーバに向ける.この論理は本文章の核心論理である.アマゾンクラウドではARPのブロードキャストは許可されていませんが、コマンドラインでNIC(ENI)のSecondary-private-ip-addressを指定できます.このコマンドの具体的な形式は次のとおりです.
aws ec2 assign-private-ip-addresses --network-interface-id $ENI --private-ip-addresses $VIP --allow-reassignment
上記の式では、ENIはNICのインスタンスId、ENIはNICのインスタンスId、ENIはNICのインスタンスId、VIPは仮想IPを指す.このコマンドが実行されると、アマゾンクラウドのネットワーク環境では、この仮想IPがこのコマンドを実行したマシンを指し、IP切り替えが完了します.
次はKeepAliveDに関する構成です.
notify_master "/home/keepalived/scripts/mysql_be_master.sh 172.*.*.201 eni-*"
テストにより、以上の方法でアマゾンクラウド(AWS)でイントラネットリソースサーバ(データベース、キャッシュサーバなど)の高可用性を実現することができます.
参照ドキュメント:http://fredlong.iteye.com/blog/2233236