フェイルセーフWebサービスの実行方法

まえがき



この記事では、フォールトトレラントなWebサービスを構築した経験についてお話ししたいと思います。 PHP + MySQL(企業ポータル)で内部エンタープライズ管理システムを開発しましたが、企業のほぼ全期間がこのシステムの操作性に依存しているため、フォールトトレランスの問題は非常に重要です。 同時に、企業は小規模であるため、高価な鉄と技術を購入する余裕がなく、数時間の単純なシステムでも致命的ではありません。 したがって、私は最小限の財政投資でこの問題を解決しようとしましたが、私自身でそれを行い、管理分野の知識はほとんどありませんでした。



この記事は、Heartbeat、DRBD、OCFS2、MySQL Clusterを使用する専門家にとって明らかに興味深いものではないことを、すぐに言いたいと思います。 しかし、もしあなたがこれに慣れていないなら、数人のシステムエンジニアのためのお金しかなく、あなたは信頼できるシステムを構築したい、そして...私が得たものを読んでください。



挑戦する



サーバーの1つに障害が発生したときに、作業が自動的に作業サーバーに切り替わる古典的なフェイルセーフシステムを構築することを実現しましたが、まだできません。次のタスクを自分で設定します。 1台がマスターとして機能し、2台目がスレーブとして機能する2台のサーバーのシステムを構築するために、マスターシステムに障害が発生した場合、エンタープライズシステム管理者は手動でネットワークケーブルをスレーブに切り替えて作業を続行します。 さらに、メインの機能をゆっくりと復元し、システムをダウンタイムなしで通常の動作モードに戻すことができます。 これは、顧客の要件を完全に満たしました。



一般的なソリューションスキーム



そこで、システムを作成するために、次の構成の低コストシステムユニットを2台購入しました(合計コストは30トンをわずかに超えていました)。



2つのネットワークインターフェイスを持つメインサーバーと3つのネットワークインターフェイスを持つスレーブサーバーが判明しました。



企業ポータルを実行するプラットフォームとして、VMWare仮想マシンとして実行されるUbuntu Linux 8.04.4に基づくLAMPを使用します。 実際、私はLAMPの設定に大きな専門家ではないので、専門家を信頼し、完成した1C-Bitrix仮想マシン( http://www.1c-bitrix.ru/products/vmbitrix/ )を基礎とします。



サーバーで仮想マシンを実行するために、無料のVMware vSphere HypervisorTM(ESXi)vをインストールするオプションを決定しました。 4.1ベアメタル。両方のサーバーに最初にインストールされました。 このハイパーバイザーはミニオペレーティングシステムであり、その機能は仮想マシンの管理に集約されます。 インストールは問題なく行われましたが、後でわかったように、結局、ハードウェアはESXiと完全に互換性がありませんでした。 このテーマについては、インターネットで見つけたホワイトリスト( http://www.vm-help.com/esx40i/esx40_whitebox_HCL.phpおよびhttp://ultimatewhitebox.com )のすべてのコンポーネントをチェックしました。 非互換性は、ESXiがサーバーハードウェアの状態に関するすべての診断情報を表示しなかったという事実に表れていました。 それは問題ではないようですが、それでもあまり良くありません。



次に、LAMPとその企業ポータルを備えた同一の構成済み仮想マシンを両方のサーバーにコピーしました。 次に、ESXiでネットワークインターフェイスをセットアップします。 メインサーバー(2つのLANインターフェースのみ):ESXiへのアクセス用に1つのネットワークインターフェースが構成され、両方とも仮想マシンに「結び付けられています」。 スレーブ(3つのLANインターフェースのみ):1つのインターフェース-ESXiへのアクセス用、および2つの仮想マシンに「接続」されています。



仮想マシンに関連付けられたネットワークインターフェイスを介して両方のサーバーに直接接続されたケーブル。 仮想マシンでは、顧客のLAN(172.20.15.0-255)以外のサブネットからこれらのネットワークインターフェース(マスターには10.10.10.2、スレーブには10.10.10.3)に割り当てられたIPアドレス。 このサーバー間の直接接続は、2台のサーバーの仮想マシンが互いに「通信」すること、つまりMySQLデータを複製し、フォルダーをスクリプトと同期することのみを目的としています。



メインサーバーは、2番目のインターフェイスを介して、企業のローカルネットワークに接続されます。 ESXiを操作するためのインターフェイスを介したスレーブサーバーもローカルネットワークに接続され、仮想マシン用に設計された3番目のインターフェイスは未接続のままでした-通常モードでは使用されません。



仮想マシンのマスターサーバーとスレーブサーバーで、仮想マシンが「見る」2番目のインターフェイスに同じIPを割り当てました。 通常モードでは、ネットワークケーブルはメインサーバーのこのインターフェイスに接続され、障害が発生した場合は、このケーブルをスレーブサーバーの対応するインターフェイスに切り替える必要があります。 なぜなら そこにIPが同じに設定され、それ以上の設定は不要であり、作業を続行できます。



したがって、通常モードおよびメインサーバの障害時のシステム操作の次のスキームが取得されました。

画像



画像



ニュアンスについて少し説明します。



サーバーを相互に接続するケーブルで、マスター(マスターにした)サーバーとスレーブ(スレーブにした)サーバー間でMySQLの標準レプリケーションを構成しました。 このテーマには多くの優れた資料がありますが、説明する意味はありません。 私の意見では、興味深いかもしれないいくつかの点について説明したいと思います。



MySQLレプリケーションステータスの監視。


職場では、レプリケーションが中断されたかどうかを簡単に確認できるようにしたかった。 毎回、ESXiのコンソールまたはマスターサーバーから下位の北にアクセスするのは大変です。 この問題を解決するために、PHPのスクリプト(checkslave.php)をスレーブサーバーにコピーしました。その主な機能は、MASTERとSLAVEからレプリケーションステータスを取得し、テーブルに表示することです。 マスターサーバーはスレーブに問い合わせることができません。 MySQLでは、彼にはこれに対する権利はなく、部下は主要なものにアクセスする権利を持っていますが、その逆はできません。 次のコマンドを実行すると、ステータスが取得されます。

SHOW SLAVE STATUS





そして

SHOW MASTER STATUS







なぜなら ユーザーはメインにのみアクセスでき、その上にcronにコマンドを追加しました:

wget --no-check-certificate 10.10.10.3/checkslave.php -O /var/www/checkslave.html



wget --no-check-certificate 10.10.10.3/checkslave.php -O /var/www/checkslave.html



。これは、スレーブサーバーからcheckslave.phpを要求し、その出力をメインサーバー上のhtmlファイルに保存します。 したがって、ブラウザでメインサーバー上のこのファイルを確認し、レプリケーションに問題があるかどうかを確認できます。



複製ブレーク保護。


作業中に、スレーブサーバーで実行されているSQL変更要求中にレプリケーションが簡単に壊れるという事実に出会いました。 これにより、すぐに一意のキーに複製が作成され、一般にデータの不整合が発生しました。 その上で企業ポータルに入るだけで十分であり、複製は中断されました。 レプリケーションの信頼性を高めるために、次を追加しました。 スレーブサーバーに2つのPHPスクリプトを追加しました。1つは企業ポータルのスクリプトが動作するMySQLユーザーへの変更に対する権限を与え、2つ目はSQL GRANT



およびREVOKE



を使用してこれらの権限をREVOKE



。 制御スクリプト自体は、MASTERおよびSLAVEのステータスをポーリングするのと同じスクリプトの下で、異なるユーザーの下でMySQLに接続されます。



次に、スレーブサーバーがマスターサーバーと接続しているかどうかを確認する小さなスクリプトを作成し、それに応じてスクリプトを実行して、変更のためにスレーブサーバーデータベースを開閉します。 スクリプトは5分ごとにスケジュールに従って実行されます。 したがって、切断後5分が経過すると、ユーザーはスレーブサーバーで作業できるようになり、接続が切断されていない場合、スレーブサーバーは変更に対して閉じられたままになります。

#!/bin/bash



count=$(ping -c 8 10.10.10.2 | grep 'received' | awk -F',' '{ print $2 }' | awk '{ print $1 }')

if [ $count -eq 0 ]; then

php -f /folder/slave_open.php

else

php -f /folder/slave_close.php

fi









スクリプトの同期。


データベースの同期に加えて、マスターに変更が加えられると、PHPスクリプトおよびその他の作業ファイルもスレーブサーバーで変更されることが重要です。 この問題を解決するために、スケジュールに従ってスレーブサーバーにコマンドを追加しました。

rsync -avz 10.10.10.2:/var/www/ /var/www







ファイルを使用した企業ポータルの作業。


PHPスクリプトに加えて、企業ポータルはユーザーファイルを管理します。ユーザーファイルは、マスターサーバーとスレーブサーバーの両方でアクセス可能でなければなりません。 これを可能にするために、Windows Server 2008を実行している企業の別のファイルサーバーにこれらのファイルのストレージを配置しました。そこに別のフォルダーを作成し、両方の仮想マシンでこのフォルダーがマウントされたディスクにあるかどうかを確認し、ない場合はマウントするスクリプトを作成しました。

flag=0

mnt_path='/folder'

mnt_test=`mount -t cifs`

flag=`expr match "$mnt_test" '.*folder.*'`

if [ "$flag" = "0" ]

then mount -t cifs -o username=user,password=pass,uid=bitrix,gid=bitrix,iocharset=utf8,codepage=866 //172.20.15.21/portal_folder /folder

fi









さらに、すべてのPHPスクリプトは、このマウントされたフォルダーの特定のシステムにユーザーファイルを保存します。 作業がスレーブサーバーに切り替えられた場合、ネットワークケーブルが含まれていて誰もが作業を続行すると、このフォルダーもすぐにマウントされます。 また、両方のサーバーに障害が発生した場合でも、ファイルサーバー上のファイルを直接使用できます。



最後まで読んでくれてありがとう!




All Articles