こんにちは、読者の皆様。
繰り返しになりますが、プロジェクトの1つでは、信頼性を高めてFTPサーバーを編成することが目標でした。 信頼性の向上とは、次のことを意味します。
- データはAWS S3に保存されます
- FTPサーバー自体（Pure-ftpdが選択されている）は、可能な限りアクセス可能でなければなりません。
- 負荷分散を整理する（オプション）
ステップ1 ：s3fsをインストールし、S3バケットをディスクパーティションとしてマウントします。
多くのオプションはなく、むしろ1つ（私が間違っている場合-正しい）
-s3fsです。 s3fs開発者のページでは、
「s3fsは安定しており、多くの運用環境で使用されている
」と主張してい
ます 。 s3fsのインストールプロセスは意味をなさないので、
ここにあります 。 新しいファイルをS3にアップロードすると、すぐにサーバーに表示されますが、後でS3でこのファイルに変更を加えても、古いバージョンはサーバーに残ります。 キャッシングに問題があります。 キャッシュをオンまたはオフにするためのさまざまなオプションを使用してS3バケットをマウントしようとして失敗しました。 さまざまなs3fsリリースをテストした後、このバグが現れない
バージョンが見つかりました。 パッケージをダウンロードし、解凍して、Makefileに記述されているとおりにインストールします。 s3fsが正しく機能するためには、次のパッケージがシステムに既にインストールされていることを確認してください。
確認するには、次のコマンドでバケットをマウントしてみてください：
ステップ2 ：pure-ftpdをインストールします。
面白くないようです。 任意のパッケージマネージャーを使用してインストールするだけです。 ただし、pure-ftpdは妄想的であり、ファイルを削除する前に、まずそのファイルを新しい一時ファイルにコピーします。 また、ファイルサイズが数ギガバイトの場合、この手順には余分な時間がかかります。 そして、私たちの場合、データがローカルではなくS3に保存されている場合、短時間ではありません。
削除する前に一時ファイルの作成を無効にするために、--
without-sendfileオプションを使用してpure-ftpdを再構築しました。 もちろん、パッケージを組み立ててシステムにインストールする方が正しいでしょうが、私はすぐにそれを行い、気を散らしませんでした。
ステップ3 ：ユーザー権限を構成します。
最も興味深いニュアンスの1つ。 顧客の要件に応じて、各ユーザーのホームフォルダーには、ユーザーが削除または書き込みできないディレクトリが必要です。 通常のディスクパーティションを扱っている場合は、フォルダの所有者を変更するだけで済みます。 ただし、この場合、パーティションがマウントされているオプション（roまたはrw）から権限が継承されるため、これは機能しません。 つまり、ユーザーはすべてを読むことも、単に読むこともできます。 ただし、pure-ftpdには便利な機能が1つあり、リンクを「追跡」できます。 これを行うには、アセンブリ中に別のオプション
--with-virtualchrootを追加します
。 したがって、バケットを
読み取り専用モードと
読み取り/書き込みモードで2回マウントし、ユーザーのホームディレクトリにバケットへのリンクを作成できます。
ユーザーディレクトリは次のようになります。
ls -la /mnt/Users/User1/ . lrwxrwxrwx 1 root root 15 Mar 25 09:10 mybucketro/folder1 -> /mnt/mybucketro/folder1 lrwxrwxrwx 1 root root 15 Mar 25 09:10 mybucketrw/folder2 -> /mnt/mybucketrw/folder2
これで、ユーザーに
/ mnt / mybucketro / folder 1
フォルダーへの読み取りアクセス権と
/ mnt / mybucketrw / folder2フォルダーへの書き込みアクセス権を与えました。この段階で、最初のTKアイテム（データはAWS S3に保存されます）が完了したと想定できます。
ステップ4 ：高可用性を構成します。
ここでは、古き良きAWS LoadBalancerとその素晴らしいHealthCheckを使用することにしました。
AWSコンソールを開き、新しいバランサーを作成します（バランサーを作成するプロセスを繰り返す必要はないと確信しています。その場合、ここに
リマインダーがあります ）。
[Pingプロトコル]で、[TCP]、[Pingポート-21]を選択します。
これで、サーバーの実行可能性は21ポート、つまりFTPサーバーの可用性によってチェックされます。
サーバーからAMIを作成します（FTPは既に構成されており、パーティションがマウントされています）。 さらに、いつものように、作成したAMIでlaunch-configを実行し、自動スケーリンググループを作成します。
自動スケーリンググループを作成するとき、新しいロードバランサーと--health-check-type ELBオプションを指定します。この構成では、FTPサーバーが「クラッシュ」した場合、ロードバランサーはそれを削除し、新しい作業サーバーを「レイズ」します。 S3に保存するすべてのデータは、この手順によって害を受けることはありません。
ステップ5（オプション）ベストプラクティスは大歓迎です ：負荷分散と自動スケーリングを設定します。
FTPの負荷を分散する問題は、たとえばWebの負荷ほど簡単には解決されません。 私はこれに初めて直面し、既製の無料ソリューションを見つけられず、CSNを使用して負荷を分散することをお客様に提案しました。
AWS Route53には、Aタイプエントリのオプション-weightがあります。 レコードの値が高いほど、クライアントへの応答時の優先度が高くなります。
つまり、理論的には、同じ重みで5つのレコードを作成し、5つのサーバーにクライアントリクエストを均等に分散させることができます。 エントリを追加するもの：
削除する別の：
スクリプトは、python-botoパッケージに付属する
route53ユーティリティを使用します。
AMIを作成するサーバーに両方のスクリプトを配置し、Pure-Ftpd起動スクリプトに呼び出しを追加します
これで、起動時に、Pure-Ftpd自体がIPアドレス付きの新しい「A」レコードをAWS Route53に追加し、オフになると削除されます。
自動スケーリンググループにScaleUPおよびScaleDownのポリシーを追加するだけです。
それが全体のセットアップです。 この構成は、プロジェクトで6か月間正常に機能しています。
ご質問がある場合は、コメントを書いてください。可能な場合はお答えします。 また、誰かがそのようなシステムを組織した経験を共有してくれたら嬉しいです。