2

当初の私の問題は、「最初にIPアドレスを見つける必要なしにEC2インスタンスにRDPする方法」でした。これを解決するために、各インスタンスで定期的に実行されるスクリプトを作成しました。スクリプトは特定のタグ値を読み取り、Route53の対応するエントリをインスタンスのパブリックDNS名で更新します。

このようにして、いつでもweb-01.ec2.mydomain.comにrdpして、適切なインスタンスに接続できます。

インスタンスのセットアップを続けると、mongodbレプリケーションをセットアップすることに気付きました。どういうわけか、3つの別々のインスタンスを参照する必要があります。内部プライベートIPアドレスは変更され続けるため、使用できません（または、インスタンスの停止/開始時およびdhcpリースの有効期限が切れたときに変更される傾向があります）。

EC2インスタンス内からアクセスしようとするとweb-01.ec2.mydomain.com、インスタンスの内部IPアドレスが返されます。これは標準的な動作のようです。したがって、3つのインスタンスのroute53 cnamesに言及することで、それらが常に相互に検出できるようにすることができます。cnamesは常に内部IPに解決されるため、追加のデータ転送料金を支払う必要はありません。ただし、route53クエリのすべてに料金を支払うことになります。

DNSエントリが可能な限り最新であることを確認するために、30秒以下ごとにスクリプトを実行できます。

この時点で、私が用意しているのは非常にElasticIPの代替手段であることに気づきました。完全ではないかもしれませんが、確かに私のすべてのユースケースに当てはまります。ですから、ElasticIPを使うかどうか疑問に思っています。インスタンスが実行されている限り、料金はかかりません。それはより簡単なオプションのようです。

ほとんどの人は何をしますか？ これを経験した方がいらっしゃいましたら、よろしくお願いします。

次に、インスタンスが現在のプライベートIPを失い、新しい内部IPを取得する数秒/分で何が起こるか。既存のすべての接続が切断されると想定しています。これはELBヘルスチェックに影響しますか（30秒ごとにpingを実行します）？Elastic IPを使用している場合、スクリプトの実行後とは対照的に、DNS名はすぐに新しいIPに解決されると想定しています。スクリプトが30秒ごとに実行されると仮定すると、ダウンタイムは30秒だけになるのでしょうか、それとももっと長くなる可能性がありますか？Elastic ipは、スクリプト化されたソリューションよりも常に優れたパフォーマンスを発揮しますか？

4

2 に答える 2

4

AWSの公式ドキュメントによると、「プライベートIPアドレスは、その存続期間中はインスタンスに排他的に関連付けられ、インスタンスが停止または終了したときにのみAmazon EC2に返されます。AmazonVPCでは、インスタンスは、インスタンスが停止。"。したがって、それでも30秒ごとに何かが変更されたかどうかをチェックすることは、本質的に間違っているように思われます。これにより、2つの明らかなオプションが残ります。

  • 起動時/起動後にDNSを1回更新します
  • エラスティックIPとスタティックDNSを使用する

使用済みのエラスティックIPは費用がかからず、駐車したIPでもわずかな費用しかかかりません。インスタンスがほとんど稼働している場合は、エラスティックIPを使用してください。それらがほとんどダウンしている場合は、起動時の更新ルートに移動します。インスタンスがVPCにある場合、起動時の更新でさえ厳密に必要とされるわけではありません（ただし、VPCでは、おそらく異なるニーズと、より複雑なネットワーク設定があります）。

于 2012-12-04T07:28:49.127 に答える
1

検討できるもう1つのオプションは、 AmazonVPCやRavelloSystemsなどのソフトウェア定義のデータセンターソリューションを使用することです（免責事項：当社）。

このようなソリューションを使用すると、パブリッククラウドに壁に囲まれたプライベート環境を作成できます。環境内では、IPアドレス指定を管理し、静的に割り当てられたIPなどを使用できる独自のプライベートL2ネットワークを含め、完全に制御できます。外部（アプリサーバーなど）との通信は、構成したIPとポートを介して行われます。

于 2012-12-04T16:31:55.177 に答える