実際、ベンダーのウェブサイトにアクセスすると 、次のことがわかります。
「1C-Bitrix：Web環境」-LinuxベースのCentOS 6（i386、x86_64）およびCentOS 7（x86_64）Linuxプラットフォームで1C-Bitrix製品およびソリューションの動作に必要なすべてのソフトウェアを迅速かつ簡単にインストールするためにLinuxが使用されます。 Webサーバーがインストールされていない「クリーンな」CentOSにインストールする必要があります。
「1C-Bitrix：Web環境」の構造-Linuxには、mysql-server、httpd、php、nginx、nodejs push-server、memcached、stunnel、catdoc、xpdf、munin、nagios、sphinxが含まれます。
実際、このソフトウェアパッケージには、構成済みのLAMP、コンソールサーバーコントロールパネル、および一部の1C-Bitrixモジュールの動作に必要な追加パッケージが含まれています。 すべてのソフトウェアは、1C-Bitrixの機能を考慮して構成されています。
- 必要な拡張機能がインストールされています（gd、zip、socket、mbstring）
- ショートタグサポートが有効
- 必要な値は、パラメーターmemory_limit、max_input_vars、セーフモード、opcache.validate_timestamps、opcache.revalidate_freq、mbstring.func_overload、default_charset、display_errorsなどに設定されます。
- データベース、PHP、およびサーバー自体に同じタイムゾーンを設定します
- その他
これにより、ほとんどの場合、サーバーの構成とチューニングを行わないことができます。
そのため、2台のアプリサーバー（app01とapp01と呼びます）、2台のdbサーバー（db01、db02）、1台のキャッシュ用サーバー（cache01、ご理解のとおり）、より正確には、同様の方法でクラスター構造を実装するというアイデアがありました。 この計画では、最新のcentos7バージョンがインストールされた5つのサーバーが受信されました（残念ながら、debian、ubuntu、fedora、rhelなどは適切ではありません）。ただし、osを除き、サーバーには何もインストールされませんでした。
なぜなら クラスタを構築する場合、どのサーバーがメインサーバーになるかを決定する必要があります。 アプリケーションへのリクエストのバランスをとるという特性のため、httpdが機能するサーバーの1つにもnginxが含まれます。 また、すべての着信要求を受け入れ、利用可能なWebノードの1つに要求をリダイレクトします。 メインサーバーapp01を選択しました。
次の計画に従って、さらに作業を進めました。
1. bitrixenvをインストールします
インストールは、超自然的なLinuxの知識や管理を意味するものではありません。 sshを介して各サーバーにアクセスし、次のコマンドを実行します。
cd ~ wget http://repos.1c-bitrix.ru/yum/bitrix-env.sh chmod +x bitrix-env.sh ./bitrix-env.sh
Bitrixenvは、クラスターで使用する予定のすべてのサーバーにインストールする必要があります。 サーバーがmemcachedインスタンスとしてのみ機能する場合でも、bitrixenvが必要です。 メインサーバーからクラスター全体を管理できます。
2. bitrixenvを構成する
なぜなら この動物園全体をクラスターとして使用する場合、app01の環境メニューからサーバーを構成できます。 これを行うには、sshを介してサーバーにアクセスし、ファイル/root/menu.shを実行します。 最初の起動時に、bitrixユーザーのパスワードを設定する必要があります（サイトの起動がスケジュールされているすべてのサーバーで同様の操作を実行する必要があります）。
実際、これはアプリケーションが動作するユーザーです。 その後、サーバープールを作成するための画面が表示されます。
ここでは、最初のメニュー項目を選択する必要があります。 環境を作成するプロセスでは、現在のサーバーの名前を要求し、app01を指定します。
プールが作成されると、環境の最初の画面に戻りますが、今回はさらに多くのポイントが利用できます。
一般に、環境は準備が整っており、使用できます。 クラスタが不要な場合は、ここで終了できますが、さらに先に進みます。
次に、使用可能なすべてのサーバーを作成されたプールに追加する必要があります。 これを行うには、最初のメニュー項目を使用して、次のオプションを確認します。
繰り返しますが、最初のメニュー項目を選択し、新しいサーバーのIP、クラスター内の名前（同じapp02、db01、db02、cache01）、および接続されたサーバーのルートパスワードを指定します。 したがって、使用可能な各サーバーを1つずつ追加します。 すべてのサーバーがクラスターに登録されると、環境のメイン画面に次のリストのようなものが表示されます。
今のところサーバーの役割を設定することは、次のステップに延期されます。
3.プロジェクトの転送
なぜなら アプリケーションは最初は単一のサーバーで実行されるため、スケーリングおよびクラスター管理モジュールが無効になっているため、データベースは複製されません。 転送自体は超自然的なものではありません。bitrixとアップロードフォルダーは圧縮され、データベースダンプは削除されました。
アーカイブとダンプの準備が整ったら、app01に移動し、プロジェクトコードをgitからbitrixenv-/ home / bitrix / wwwのデフォルトサイトフォルダーにプルし、wgetまたはcurlを使用してアーカイブとデータベースのダンプをダウンロードし、アーカイブをアンパックしてアップロードしますapp01のデータベースにダンプし、cronエントリを転送します。
アプリケーションで追加のソフトウェアを使用している場合は、インストールして構成します。 この例では、supervisordとRabbitMQがインストールされ、構成されています。 アプリケーションはキューを使用して機能しました。
小さいながらも重要なニュアンスがあります。 サイトをクラスターに転送する場合、スケールおよびクラスターモジュールがサイトで無効になっている必要があり、プールサーバーは転送が計画されているクラスターの環境に関与していません。 サイトをメインサーバーに移動して展開した後にのみ、クラスターサーバーを操作に含める必要があります。 そうしないと、サイトはクラスターサーバーを正しく判別できません。
4.クラスターモードの有効化
アプリケーションをapp01に移植し、その作業の正確性を確認したら、最も興味深いことであるスケーリングを行います。 最初に、1C-Bitrix管理パネルにスケールおよびクラスターモジュールをインストールする必要があります。 インストール中、特別な作業は必要ありません。すべての作業が続行されます。
モジュールがインストールされたら、メインサーバー（これはapp01）とのssh接続に移動し、bitrixenvメニューを開きます（ここでは/root/menu.shにあります）。 さらに設定を進める前に、1つの重要なポイントを見つける必要があります。bitrixenvは「サーバーロール」の概念で動作します。 プール内でサーバーが何と呼ばれるかは、実際には問題ではありません。 各サーバーにはbitrixenvパッケージに含まれるすべてのソフトウェアが含まれており、いつでも1つ以上のロールを割り当てることができます。また、サーバーからそれらを削除したり、他のサーバーと交換したりできます。 主な役割は、mgmt（バランサー、つまりnginx）、web（つまりhttpd / apache）、mysql_masterおよびmysql_slave（DBインスタンス、レプリケーションを開始するとスレーブが表示される）、memcached（memcachedを備えたサーバー）です。 これで全体像が明らかになり、memcachedサーバーから始めることにしました。 これを行うには、段落に移動します
4. Configure memcahed servers > 1. Configure memcached service
そして、memcachedサーバーとして機能するサーバーの名前のリクエストが表示されます。 このためにcache01サーバーがすでに準備されているため、使用可能なサーバーのリストを確認します。 cache01がリストにある場合、インストールに問題はありません。選択したロールをサーバーに与えることができます。
名前cache01を入力すると、ロールを設定するタスクがキューに入れられていることがわかります。 バックグラウンドの作業が完了するのを待っており、必要な役割で作業できる状態のサーバーが表示されます。
2番目のアプリサーバーを追加します。 これを行うには、パスに沿って移動します
8. Manage web nodes in the pool > 1. Create web role on server,
ここで、メインと新しいWebノードの間のサーバー名と同期方法を指定する必要があります。 bitrixenvのドキュメントと予備テストに基づいて、プロジェクトが最初のオプションを選択するだけで十分でした（プロジェクトをコピーし、1ステップでノード構成をセットアップする）。 バックグラウンド作業が終了すると、メインメニューに次のようなものが表示されます。
app02サーバーの反対側の「役割」列に、Web役割が示されていることに注意してください。
データベースを処理するために残り、その構成に最も時間がかかります。 最初に、bitrixenvのコンテキストでmysqlロールがどのように分散されるかを簡単に説明します。 デフォルトでは、データベースのマスターバージョンはクラスターのメインサーバーにあります。 この場合、データベースを別のサーバーに転送し、データベースのスレーブバージョンで別のサーバーを追加する必要がありました。 bitrixenvでは、1つのサーバーから別のサーバーにマスターを取得して転送することはできません）
シーケンスは次のとおりです。
- データベースの転送先のサーバーにmysql_slaveの役割を与えます
- ターゲットサーバーで、mysql_slaveのロールをmysql_masterのロールに変更します（自動的に、古いmysql_masterはmysql_slaveモードになります）
- 元のサーバー、元のマスターでmysql_slaveロールを削除します
- ...
- 利益!!!
このロジックは次のとおりです。
に行った
3. Configure MySQL servers > 4. Create MySQL slave
ロールmysql_slave-db01を付与するサーバーを指定しました。 バックグラウンド作業の終了を待っており、次の結果が表示されます。
さて、今に行きます
3. Configure MySQL servers > 5. Change MySQL master
app01を指定して待機します。 その結果、次のように表示されます。
ゆっくりと必然的に、最後のロールmysql_slaveのインストールに近づきました。 そのためには、db01にそのようなロールを設定する手順を繰り返す必要がありますが、db02は既に指定しています。
最後に、すべてのサーバーが接続および構成されます。
5.パフォーマンスの調整
クラスターの準備が整うと、アプリケーション構成に追加の最適化を可能にする機能がいくつかあります。
- セッションを使用して作業をポンプで送ります。 ここで詳細に説明します 。 要するに-memcachedでセッションストレージを切り替えます。
- ファイル/bitrix/php_interface/after_connect_d7.phpおよび/bitrix/php_interface/after_connect.phpを削除します。 それらからのコマンドはクラスターパイプラインを中断します（bitrixenvを使用しない場合は、そのままにしておくことをお勧めします）。
- memcachedによって割り当てられるメモリの量を増やし、memcachedロールを持つサーバーの使用率を100％に設定します。
- PHPモジュールの無効化：apcu、ldap
- バスモジュール「圧縮」および「Web分析」を無効にします（可能な場合）。
- ローカルキャッシュの使用を検討してください。 詳細については、 こちらをご覧ください 。 私たちの場合、増加はありませんでしたが、このアイデアは興味深いものです。 ソリューションにはいくつかの機能があります。
- memcachedインスタンスの数は、Webノードの数と等しくする必要があります。
- ローカルmemcachedから直接nginxによって複合キャッシュを返すには、nginxの設定を掘り下げる必要があります。そのままでは機能しません。
- すべてのエージェントの実行をcronに移動します。
結論
この記事のフレームワークでは、bitrixenvに基づいてサーバークラスターを構成するために必要な手順のシーケンスと、考えられるいくつかの落とし穴を調べました。 bitrixenvとそのクラスターの操作の結果に基づいて、このアプローチの長所と短所を強調できます。
長所bitrixenv
- 設置時間
インストールと基本的なセットアップにかかる時間は30分未満です。 LAMP要素を構成する必要はありません（これらのサービスの相互の統合、および1C-Bitrixでのプロジェクトの正しい作業のため）。 - サイトを高速化するサービス
ファイルではなくmemcachedを介した高速キャッシュの整理、sphinxエンジンを使用した検索、および企業ポータルでのビデオ通話とチャットの機能（nginxプッシュアンドプルモジュール）を可能にするインストールおよび構成されたサービス。 さらに、環境のnginxは、サイトおよびbitrixenvメニューで対応するオプションが有効になっている場合、memcachedから直接nginxを使用してキャッシュが送信されるように構成されます（httpdおよびphpをバイパス） - クラスタリング
MySQL設定を選択せずにデータベース複製を有効にする機能。 自動的に相互に同期される任意の数のWebノードとmemcachedノードを接続します。 bitrixenvメニューと1C-Bitrixのプロジェクトの管理パネルの両方からの、Webおよびmemcachedノードでの負荷分散の管理。 さらに、新しいサーバーとロールを追加しても、単純なプロジェクトは発生しません（データベースサーバーのロールを除く）
短所bitrixenv
- バランサーは常にメインWebノードを使用します
なぜなら すでに独自のバランサーがあり、bitrixenvに組み込まれたバランサーを放棄することは不可能であるという事実に直面しました。 など不可能です メインWebノードとは別に配置します。 - いくつかの役割のための多くの追加ソフトウェア
なぜなら プール内の各サーバーには完全なバージョンの環境が含まれているため、使用されていなくても、dbノードはhttpd、memcached、sphinxであることがわかります。 同様に、キャッシュのみを処理するサーバーでMySQLに対応できますが、この場合、MySQLは環境メニューまたはサイトの管理パネルで停止できます。 - PHPはapache2handlerモードで動作します
nggix + php-fpmモードは言うまでもなく、fcgiモードでphpを安全に有効にする方法はありません。 また、タンバリンと踊らなければ、PHPバージョンを変更することはできません。
ソース：
www.1c-bitrix.ru/products/env
dev.1c-bitrix.ru/community/blogs/rns/hidden-features-of-work-with-sessions.php
dev.1c-bitrix.ru/community/blogs/rns/the-use-of-local-caches-in-the-cluster.php
dev.1c-bitrix.ru/learning/course/index.php?COURSE_ID=32&INDEX=Y
dev.1c-bitrix.ru/learning/course/index.php?COURSE_ID=37&INDEX=Y