Elastic IP アドレスのない EC2 インスタンスで cassandra を使用できますか? その場合、インスタンスがダウンすると問題が発生すると思います。
Cassandra ノードに Elastic IP アドレスを使用する場合、内部通信 (ゴシップなど) にパブリック IP アドレスを使用するように構成する必要があります。しかし、それはネットワーク遅延を増加させます。
問題を最小限に抑えるためにノードを構成する方法を提案してください。
Elastic IP アドレスのない EC2 インスタンスで cassandra を使用できますか? その場合、インスタンスがダウンすると問題が発生すると思います。
Cassandra ノードに Elastic IP アドレスを使用する場合、内部通信 (ゴシップなど) にパブリック IP アドレスを使用するように構成する必要があります。しかし、それはネットワーク遅延を増加させます。
問題を最小限に抑えるためにノードを構成する方法を提案してください。
EC2 と Cassandra で非常にうまく機能する VPN ソリューションを使用しているため、Elastic IP を使用する必要はありません。それに関するいくつかの情報は、ここで見つけることができます。
現在、このオプションは万人向けではありませんが、EC2 ノードが IP アドレスを変更し、Elastic IP を使用する必要がないという問題を軽減することができます。また、Amazon インターフェイス (内部/外部) を使用しないことでパフォーマンスが向上することもわかりました。理由を聞かないでください..私は彼らのアーキテクチャについて説明できるほど十分に知りません-ただそうであることを期待してください!
さらに、@jbellis が提案する提案をうまく活用して、RackSpace を使用することができます。EC2、RackSpace、および独自の内部ホストノードを活用できるように、混合プロバイダーのセットアップがあります。ベンダーやサービスプロバイダーにとらわれないことは、私にとって非常に重要です...
多くの人 (私を含む) は、Amazon の EC2 で cassandra を問題なく使用しています。内部 IP アドレスは自由に変更される傾向があるため、内部 EC2 DNS 名を使用するだけで済みます (パブリック IP アドレスまたはパブリック DNS 名ではなく、どちらもセキュリティ ホールになり、Amazon からすべての料金が請求されるため)。 Cassandra トラフィック)。
これは、何らかの理由で Cassandra ノードがダウンした場合、そのノードのデータが失われることを意味します (低速の永続ストレージを使用している場合を除く) が、これはレプリケーション ファクターを増やすことで簡単に修正できます (私たちは RF を使用します)。 =3)