問題タブ [amazon-efs]

数か月前から EFS を使用していますが、今日、バースト クレジットの残高がゼロになり、EFS が応答しなくなっていることに気付きました。現在の従量制サイズは 2.6 GiB です。ダミー データをコピーしてサイズを大きくすると、追加のクレジット残高が生成され、EFS にアクセスできるようになる可能性があることを理解しています。しかし問題は、EFS ディレクトリが非常に遅くなり、ls のようなコマンドでさえ時間がかかることです。これはデッドロック状態ですか? EFS を再度アクセスできるようにする方法や、少なくともデータを回復する方法はありますか?

EFS を使用して ecs クラスターに mongodb データを保持したいと考えています。そこで、以下のアプローチに従いました。

1. EC2 インスタンスの下にクラスターを作成しました
2. EFS を EC2 クラスター インスタンスにアタッチ
3. タスク定義とサービスを作成しました。
4. EFS マウント EC2 クラスターでサービスを実行

これで、コンテナーが更新または終了されると、すべてがスムーズに進みます。ただし、ec2 インスタンス全体が終了した場合。AWS クラウド形成は、期待どおり EFS をマウントせずに EC2 インスタンスを作成しています。EC2 インスタンスが終了し、CloudFormation によって再作成されたときに EFS を自動的にアタッチする方法を教えてください。カスタム ecs イメージも試しました。ただし、作成されるクラウド形成テンプレートがないため、インスタンスは作成されません。

AWS ECS を使用してデプロイされた WordPress 4.9.6 に基づくサイトがあり、WordPress のファイルを保存するために EFS が使用されています。データベースとして、AWS Aurora MySQL 5.7 互換インスタンスを使用します。また、コンテナー化された WordPress インスタンスにアクセスするためのアプリケーション ロード バランサーもセットアップしました。(セットアップの詳細については、以下を参照してください。)

問題の概要

このセットアップは、ほとんどの場合に機能するようです。GETつまり、サイトでリクエストを行うことができます。ログインでき、ダッシュボードが表示され、多くの場合、正常に更新されます。私が直面している問題は、更新をコミットすると、つまりPOST /wp-admin/post.php.

仕様

設定

最初に、DB インスタンス ライターにローカル dev データベースのダンプが取り込まれます。サイト自体を指すデータベース URL エントリ (たとえばsiteurl、homeオプション テーブル内) の値はhttps.

EFS は、パフォーマンス モードGeneral Purposeで作成されました。私はもともとモードMax I/Oで試しましたが、リソースはむしろ前のモードを使用することを提案しています。ただし、パフォーマンス モードを切り替えても、502 エラーの頻度は変わりません。

私の Amazon Linux ECS クラスター インスタンスは、AWS で提案されているように NFSv4.1 を使用して EFS ボリュームをマウントするようにプロビジョニングされています ( mountoptions nfsvers=4.1,rsize=1048576,wsize=1048576,hard,timeo=600,retrans=2)。

公式の WordPress イメージから派生した Docker イメージがあり、元のイメージ/usr/src/wordpressをカスタム コンテンツで更新します。wp_config.phpカスタム コンテンツには、設定した更新済みの ao が含まれています$_SERVER['HTTPS']='on';

ECS タスク定義を組み合わせて、カスタム Docker イメージを使用し、Docker コンテナー内の Docker ボリュームとして EFS ドライブにディレクトリをマウントします。ここでの結論は、タスク定義を使用して ECS サービスを作成すると、コンテナーがスピンアップして書き込み、/var/www/htmlその後 EFS ドライブで確認できることです。これはすべてうまくいくようです。

コンテナー化された WordPress インスタンスは、以前にアプリケーション ロード バランサー用に設定したターゲット グループに正常に登録されます。

その後、https プロトコルを介して自分のサイトにアクセスできます。http を使用しようとすると、計画どおり https にリダイレクトされます。ランディングページを開くことができます。ログインすると、ランディング ページを編集しようとします。

問題

ここで私は本当の問題に直面します。常にではありませんが、多くの場合、ランディング ページを更新して [更新] ボタンをクリックすると、リクエストに対して 502 Bad Gateway 応答が返されPOST /wp-admin/post.phpます。また、編集を開始してGET /wp-admin/post.php?post=2&action=edit要求されると、同じ 502 が表示されることがよくあります。

502 を取得する場合と取得しない場合のパターンはあまり見られません。テキスト コンテンツの更新と、ランディング ページへの画像の追加を試みました。502 はときどき発生しますが、常に発生するとは限りません。

また、EFS の使用と、テスト用にセットアップした 2 つの ECS インスタンス間のその後の同期の問題に関係しているのではないかと疑ったため、問題を解決しようとしました。次の試みが行われましたが、大幅な改善は見られませんでした。

• ECS インスタンスでのキャッシュを回避するために、EFS ユーザー ガイドsyncで提案されているようにマウント オプションを追加します。
• ロード バランサーのアイドル タイムアウトを増やす

最後に、ECS サービス タスクの数を 2 から 1 に減らしましたが、問題は解決しません。

502 に遭遇したときのブラウザー コンソールのエラー メッセージとして、私はしばしば、おそらく常に、次のように表示します。The character encoding of the HTML document was not declared. The document will render with garbled text in some browser configurations if the document contains characters from outside the US-ASCII range. The character encoding of the page must be declared in the document or in the transfer protocol.

では、次に何を試すべきか、問題の原因を示す兆候をどこで探すべきかについての手がかりを誰かが持っていますか?