Nextcloud：中規模企業向けのフォールトトレラント展開

共同プロジェクト管理、LDAP承認、バージョン管理とのファイル同期、および最新バージョンで台無しにされたビデオ会議を備えた企業メッセンジャーのようなもののための非常にクールなハーベスターがあります。はい、Nextcloudについて話しています。一方で、私はUnix-wayのサポーターであり、アプリケーションを個別の機能に明確に分割しています。一方、この製品は安定性が高く、何年にもわたっていくつかのプロジェクトで問題なく動作しており、追加のホイッスルが特に動作を妨げることはありません。本当にやりたいのなら、ほとんどすべてのゲームをそこにねじ込むことができます。コミュニティは活気があり、個別のアプリケーションとして利用できるさまざまなプラグインを完全に完備しています。



今日はそれを展開します。完全なステップバイステップの説明はしませんが、注意を払う価値のあるアーキテクチャの重要なポイントについて言及しようと思います。特に、負荷分散、データベースレプリケーション、およびサービスを中断しない定期的なメンテナンスについて見てみましょう。



150〜1000ユーザーの小規模企業向けにフェイルセーフバージョンで展開しますが、ホームユーザーにも役立ちます。

企業は何を必要としていますか？

どんぐりで作られた居心地の良いホームサーバーでのサービスと企業セグメントの試合の主な違いは、ユーザーへの責任です。ただし、自宅に設置する場合でも、予定されている作業や事故の可能性について警告を表示してユーザーにメッセージを送信することをお勧めします。結局のところ、あなたの友人があなたと一緒にホストしているデータを処理することを突然決定するのは土曜日の夜です。



会社の場合、たとえ小さな会社であっても、単純な重要なサービスは潜在的な損失と問題を意味します。特に、サービスに関係するプロセスが多い場合。



特に、私の経験では、Nextcloudは中小企業の間でいくつかの機能を求めています。

1. 共有ディレクトリへのアクセスと同期を提供します。
2. フェデレーション内の外部アクセスを提供するキラー機能。同僚や他の会社の同様の製品と統合できます。
3. 直接リンクを介した外部アクセスの提供。たとえば、印刷業界で働いていて、大量の大量のデータをクライアントと交換する必要がある場合に役立ちます。
4. サーバー側で実行され、LibreOfficeのフロントエンドとして機能するCollaboraドキュメントエディター。
5. チャットとビデオ通話。少し物議を醸す、完全に安定した機能ではありませんが、そこにあり、機能します。最新バージョンでは、すでに安定しています。

アーキテクチャを構築します

残念ながら、最新バージョンでは、Nextcloudエンタープライズ実装ドキュメントは有料サブスクリプションの所有者のみが利用できます。ただし、参考として、まだパブリックドメインにある古いマニュアルを使用できます。





家庭での使用と単一のインストールに一般的です。



「オールインワン」オプションは、ユーザーが少なく、定期的なメンテナンスのためにダウンタイムを許容できる限り、悪くはありません。たとえば、更新中です。また、1つのノードに配置するモノリシックスキームには、スケーリングに問題があります。したがって、2番目のオプションを試してみます。





より高いワークロードに推奨されるスケーラブルな展開オプション。



システムの主なコンポーネント：

• 1バランサー。HAproxyまたはNginxを使用できます。Nginxでのオプションを検討します。
• 2〜4個のアプリケーションサーバー（Webサーバー）。phpのメインコードを使用したNextcloud自体のインストール。
• 2DB。標準の推奨構成では、これはMariaDBです。
• NFSストレージ。
• データベースクエリをキャッシュするためのRedis

バランサー

このアーキテクチャを使用すると、障害点が少なくなります。故障の主なポイントはロードバランサーです。利用できない場合、ユーザーはサービスにアクセスできません。幸い、同じnginxの構成は、後で検討するように非常に単純であり、問​​題なく負荷を保持します。バランサーのほとんどの障害は、デーモンまたはノード全体を再起動するか、バックアップからデプロイすることで解決できます。DNSで手動トラフィックを切り替えて、別の場所にコールドリザーブを設定することは不要ではありません。



バランサーはクライアントのSSL / TLSターミネーションポイントでもあり、バックエンドとの通信は、信頼できる内部ネットワークの場合はHTTPを介して、アプリケーションサーバーへのトラフィックが一般的な信頼できないチャネルを経由する場合は追加のHTTPSを介して行うことができます。

データベース

典型的な解決策は、マスタースレーブレプリケーションでのクラスター実行におけるMySQL / MariaDBです。同時に、アクティブなデータベースは1つだけで、メインのデータベースに緊急障害が発生した場合やスケジュールされた作業中に、2番目のデータベースはホットスタンバイモードで動作します。負荷分散も検討できますが、技術的にはより困難です。MariaDB Galera Clusterをマスターマスターレプリケーションオプションとともに使用する場合、奇数のノードを使用する必要がありますが、少なくとも3つは使用する必要があります。したがって、ノード間の接続が切断されると、スプリットブレイン状況のリスクが最小限に抑えられます。

ストレージ

NFSプロトコルが提供する最適なソリューション。高負荷の場合は、IBM ElasticStorageまたはCephを検討してください。S3互換のオブジェクトストレージを使用することもできますが、これは非常に大規模なインストールの場合のオプションです。

HDDまたはSSD

原則として、中規模のインストールでは、HDDのみを使用するだけで十分です。ここでのボトルネックは、データベースから読み取るときのiopsであり、システムの応答性に大きく影響しますが、すべてをRAMにキャッシュするRedisがある場合、これは大きな問題にはなりません。また、キャッシュの一部はアプリケーションサーバーのmemcachedに保存されます。ただし、可能な限り、SSDでアプリケーションサーバーをホストすることをお勧めします。Webインターフェイスの応答性が大幅に向上します。この場合、デスクトップクライアントでの同じファイル同期は、これらのノードにHDDを使用する場合とほぼ同じように機能します。



ファイルの同期とアップロードの速度は、NFSストレージのパフォーマンスによって決まります。

バランサーの構成

例として、簡単な基​​本構成と効率的なnginxを紹介します。はい、さまざまな追加のフェイルオーバーバンは有料バージョンでのみ利用できますが、基本バージョンでもそのタスクを完全に実行します。アプリケーションサーバーは特定のクライアントのキャッシュを保存するため、ラウンドロビンまたはランダムバランシングは適切ではないことに注意してください。

幸い、これはip_hashメソッドを使用して解決されます。この場合、ユーザーのセッションは特定のバックエンドに割り当てられ、ユーザーからのすべてのリクエストがそこに送信されます。この点については、ドキュメントで説明されています。

, IP- . IPv4- IPv6- . , . , . .

残念ながら、この方法を使用すると、動的IPの背後にいて、絶えずIPを変更しているユーザーに問題が発生する可能性があります。たとえば、モバイルインターネットを使用しているクライアントでは、セルを切り替えるときにさまざまなルートに沿ってスローできます。この問題を解決するスティッキークッキーは、有料版でのみ利用できます。



nginx構成ファイルは、これを次のように記述しています。

upstream backend {
    ip_hash;

    server backend1_nextcloud.example.com;
    server backend2_nextcloud.example.com;
    server backend3_nextcloud.example.com;
    server backend4_nextcloud.example.com;
}

この場合、負荷はアプリケーションサーバー間で可能な限り均等に分散されますが、クライアントが特定のセッションにバインドされているため、負荷の不均衡が発生する可能性があります。中小規模のインストールの場合、これは無視できます。バックエンドのパワーが異なる場合は、それぞれの重みを設定できます。次に、バランサーは指定された重みに比例して負荷を分散しようとします。

upstream backend {
    ip_hash;

    server backend1_nextcloud.example.com weight=3;
    server backend2_nextcloud.example.com;
    server backend3_nextcloud.example.com;
}

上記の例では、受信した5つのリクエストのうち、3つがバックエンド1に、1つがバックエンド2に、1つがバックエンド3に送られます。



アプリケーションサーバーの1つに障害が発生した場合、nginxはバックエンドのリストから次のサーバーに要求をリダイレクトしようとします。

データベースの構成

マスタースレーブ構成の詳細は、メインドキュメントに記載されています。



いくつかの重要なポイントを見てみましょう。まず、データ複製用のユーザーを作成します。

create user 'replicant'@'%' identified by 'replicant_password';
grant replication slave on *.* to replicant;
flush privileges;

次に、マスター構成を編集します。

sudo nano /etc/mysql/mariadb.conf.d/50-server.cnf 

「ロギングとレプリケーション」ブロックの領域で、必要な編集を行います：

[mysqld]
log-bin         = /var/log/mysql/master-bin
log-bin-index   = /var/log/mysql/master-bin.index
binlog_format   = mixed
server-id       = 01
replicate-do-db = nextcloud
bind-address = 192.168.0.6

スレーブで構成を構成します。

sudo nano /etc/mysql/mariadb.conf.d/50-server.cnf 

「ロギングとレプリケーション」ブロックの領域で、必要な編集を行います：

    [mysqld]
    server-id       = 02
    relay-log-index = /var/log/mysql/slave-relay-bin.index
    relay-log       = /var/log/mysql/slave-relay-bin
    replicate-do-db = nextcloud
    read-only = 1
    bind-address    = 192.168.0.7

両方のサーバーを再起動します。

sudo systemctl restart mariadb

次に、データベースをスレーブにコピーする必要があります。

マスターでは、最初にテーブルロックを実行します。

flush tables with read lock;

次に、ステータスを確認します。

    MariaDB [(none)]> show master status;
    +-------------------+----------+--------------+------------------+
    | File              | Position | Binlog_Do_DB | Binlog_Ignore_DB |
    +-------------------+----------+--------------+------------------+
    | master-bin.000001 |      772 |              |                  |
    +-------------------+----------+--------------+------------------+
    1 row in set (0.000 sec)

データベースコンソールを終了しないでください。終了すると、ロックが解除されます。

スレーブ構成には、ここからmaster_log_fileとmaster_log_posが必要になります。

ロックのダンプと削除：

sudo mysqldump -u root nextcloud > nextcloud.sql

    > unlock tables;
    > exit;

次に、ダンプをスレーブにインポートし、デーモンを再起動します。

sudo mysqldump -u root nextcloud < nextcloud.sql
sudo systemctl restart mariadb

その後、コンソールでレプリケーションを設定します。

    MariaDB [(none)]> change master 'master01' to     
    master_host='192.168.0.6',     
    master_user='replicant',     
    master_password='replicant_password',     
    master_port=3306,     
    master_log_file='master-bin.000001',     
    master_log_pos=772,     
    master_connect_retry=10,     
    master_use_gtid=slave_pos;

起動して確認します。

> start slave 'master01';
show slave 'master01' status\G;

回答にエラーがあってはならず、2つのポイントが手順の成功を示します。

Slave_IO_Running: Yes
Slave_SQL_Running: Yes

アプリケーションノードを展開する

いくつかの展開オプションがあります。

1. スナップ
2. docker-image
3. 手動更新

Snapは主にUbuntuで利用できます。複雑な独自のアプリケーションを提供するのは非常に優れていますが、デフォルトでは。しかし、それは産業環境ではかなり厄介な機能を持っています-それはそのパッケージを1日に数回自動的に更新します。また、厳密に区切られた内部ネットワークがある場合は、外部への追加アクセスを確認する必要があります。同時に、内部のリポジトリをミラーリングすることは完全に簡単ではありません。



はい、サブスクリプションチャネルがあり、メジャーリリースは、理論的には切り替えるべきではありませんが、考えてみてください。特にデータベースのデータ構造の変更を伴うことが多いため、更新プロセスを完全に制御することをお勧めします。



Docker-imageは、特にインフラストラクチャがすでにKubernetesで実行されている場合に適したオプションです。同じRedisノードは、アプリケーションサーバーの後にクラスターに移動する可能性があります。



これを行うためのインフラストラクチャがない場合は、tar.gzから手動で更新および展開するのが非常に便利で、制御可能です。



着信要求を処理するには、アプリケーションサーバーにWebサーバーをインストールする必要があることに注意してください。nginx + php-fpm7.4のバンドルをお勧めします。最新バージョンのphp-fmpにより、パフォーマンスと応答性が大幅に向上しました。

SSL / TLSの構成

新規インストールを行っていて、システムopensslの鮮度に依存するnginxパッケージに問題がない場合は、TLS1.3を確実に信頼する必要があります。特に、0-RTTやその他の機能を使用すると、キャッシングによりクライアントの再接続を大幅に高速化できる場合があります。古いプロトコルを削除するため、セキュリティも高くなります。



TLSを介してバランサーと通信するnginxアプリケーションサーバーの実際の構成を示します。

定期メンテナンス

産業環境では、アップグレードまたはさらに多くのバックアップのために最小限のダウンタイムを提供する必要があることを忘れないでください。ここでの主な問題は、データベース内のメタデータの状態と、NFSまたはオブジェクトストレージを介して利用できるファイル自体の依存関係です。



アプリケーションサーバーを新しいマイナーバージョンにアップグレードする場合、特別な問題はありません。ただし、データベース構造を更新するには、クラスターをメンテナンスモードに移行する必要があります。

負荷が最小のときにバランサーをオフにして、更新を続行します。



その後、config.php構成ファイルを保存しながら、ダウンロードしたtar.gzから手動更新プロセスを実行します。大規模なインストールでWebを介して更新することは、非常に悪い考えです。

コマンドラインを介して更新します。

sudo -u www-data php /var/www/nextcloud/occ upgrade

その後、バランサーをオンにして、更新されたサーバーにトラフィックを送信します。これを行うには、更新されていないすべてのアプリケーションサーバーをバランシングから削除します。

upstream backend {
    ip_hash;

    server backend1_nextcloud.example.com;
    server backend2_nextcloud.example.com down;
    server backend3_nextcloud.example.com down;
    server backend4_nextcloud.example.com down;
}

残りのノードは徐々に更新され、運用されています。この場合、occアップグレードを実行する必要はありません！phpファイルを置き換えて構成を保存するだけです。



バックアップするときは、スレーブへのレプリケーションを停止し、ストレージ内のファイルのスナップショットを作成すると同時に、データベースからメタデータのダンプを同時に実行する必要があります。それらをペアで保存する必要があります。リカバリは、データベースダンプとファイルから同じ期間同様に実行する必要があります。そうしないと、ファイルがストレージにある可能性がありますが、データベースにメタデータがないため、データが失われる可能性があります。