web-dev-qa-db-ja.com

自動スケーリングとNFSサーバー

私はWebサーバーがWS-1と言っており、NFSサーバーがAWSでNFS-1セットアップと言っています。 WS-1は、エラスティックロードバランサーによって管理されており、自動スケーリングされています。また、すべてのアプリケーションコードを含むEBSが/ var/wwwにマウントされています。

  • 自動スケーリング中に、別のWS-Xが起動された場合、/ var/wwwにマウントされたEBSも複製され、それに接続されますか？そうでない場合、ルートEBSボリュームでコードをホストする以外に私のオプションは何ですか？

  • NFS内のアクセスは、10.0.0.1/32（rw、...）のようにIPベースで定義されます。自動スケーリング中にさらに多くのインスタンスが起動されますが、NFSサーバーに接続して共有ディレクトリをマウントできるようにするにはどうすればよいですか？ NFSを使用してプライベートIPサブネットへのアクセスを許可したくないのですが、セキュリティグループレベルでは、NFSサーバーへのアクセスを0.0.0.0/0に許可しています。 NFSサーバーは、111、2049、4000-4002などの固定ポートを使用します。

amazon-ec2amazon-web-servicesamazon-ebsnfsautoscaling
3
Shoaibi

スケールアップ時に、EBSボリュームとそのデータは「複製」されません。この動作を実現するには、起動時に自動化する必要があります。

  1. WS-1EBSボリュームの最新のスナップショットを取得します
  2. ボリュームを作成して添付します

EBSにあるデータの量に応じて、別の方法はS3からデータをプルダウンすることです。

セキュリティグループを使用すると、app_security_group内のすべてのサーバーがnfs_server_group内の任意のサーバーにアクセスできるようにすることができます。これにより、セキュリティグループを動的に更新できます。

それが理にかなっていることを願っています。

4
Edwin

インスタンスの最近のAMI（Amazon Machine Image）が取得されている場合にのみ、インスタンスは「複製」されます。スナップショットが作成されてからファイルシステムに変更が加えられる可能性があるため、 AWS userdata を使用して、変更される領域の更新をトリガーするBash/CloudInitスクリプトを作成することをお勧めします。例えばコードベース、メディアなど。

特定の領域を更新するためのオプションは、次のいずれかになります（長所と短所のリスト）。

  1. S3の中央ストレージポイント
    • バケットにアクセスするためのアクセス許可は、インスタンスに割り当てたIAMロールを介して管理されます
    • AWSサービス間の高速I/O帯域幅
    • 一貫した稼働時間
    • Con：バケットバージョン管理 を使用しない限り、ソース管理がリビジョンに提供する柔軟性がありません
  2. データをブートストラップするためのソース管理（Git、Subversion）リポジトリ：
    • ソース管理を介してブートストラップスクリプトを動的に更新したり、貢献や履歴を残したりすることができます
    • Con：これを許可するには、Gitホストへの（潜在的に）外部接続、権限、およびセキュリティグループの構成が必要です
    • Con：おそらくS3より少し遅い

これは、起動構成に適用して、ブートストラップタスクを動的に実行するようにトリガーできるブートストラップスクリプトの例です。 userdataスクリプトはrootユーザーとして実行されることに注意してください。

#!/bin/bash
# Update your packages
yum update -y
# Get/execute bootstrapping
cd /tmp
git clone ssh://your-git-server/bootstrapping-repo.git
chmod +x /tmp/your-repo/bootstrapping.sh
# Execute it
/tmp/your-repo/bootstrapping.sh
# Remove the bootstrapping script remnants
rm -rf /tmp/your-repo

この方法により、新しいAMIを定期的に作成しなくても、「bootstrapping-repo」を必要な頻度で柔軟に更新できます。

背景として、ユーザーデータでS3を使用して、関連するSSHキー、ホストファイルなどを取得し、ブートストラップリポジトリにGitを使用します。

また、AMIを可能な限り定期的に最新の状態に保ち、起動構成に保存して、スピンアップした新しいインスタンスが自身の更新に長時間を費やす必要がないようにすることもお勧めします。これを頻繁に手動で行うか、APIまたはCLIを介して行うスクリプトを作成するかはあなた次第です。

[〜＃〜] fyi [〜＃〜]：インスタンスの起動時に呼び出されるユーザーデータと後続のスクリプトの出力はファイルに記録されます/var/log/cloud-init-output.log

0
Robbie Averill