我在Azure中有一个双节点设置,我正在尝试使用C#驱动程序连接时进行故障转移。在使用cqlsh和OpsCenter时,我的节点似乎正常通信。
var contact = "publicipforfirstnode";
_cluster = Cassandra.Cluster.Builder().AddContactPoint(contact).Build();
_session = _cluster.Connect("demo");
我最初连接第一个节点的公共IP。这很好用。但是在配置中,我使用由我的虚拟网络分配的内部网络IP,例如10.1.0.4,10.1.0.5等。我将它们设置为每个节点的listen_address和broadcast_rpc_address。即使我在配置中使用内部IP,我也可以很好地连接公共IP。我有一个特殊的防火墙规则,允许我从公共IP上的某台机器连接。但是,为了避免内部节点通信的防火墙规则,我将节点放在同一个虚拟网络上,不需要额外的工作。
在我的第一个节点发生故障之前,这似乎很棒。 然后使用内部IP尝试第二个节点。
我收到错误:所有主机都尝试查询(Public IP of First 节点),(第二节点的内部IP)
但是,由于我从不在虚拟网络中的计算机进行连接,因此无法访问此内部IP。我的应用程序不会进入内部网络,所以这似乎是一个问题。
不使用内部ips强制我设置身份验证和/或特殊防火墙规则,而不是必须这样做。有没有办法强制c#驱动程序使用公共ips并允许节点在内部ips上进行通信?除非您有多个区域,否则使用内部ips似乎是推荐的最佳做法。
答案 0 :(得分:2)
驱动程序使用cassandra.yaml文件中配置为broadcast_rpc_address
的IP连接到它们。
在您的情况下,如果您想使用公共IP地址连接驱动程序,则应将broadcast_rpc_address
设置为公共IP地址。
您可以在驱动程序中启用跟踪,以查看幕后发生的情况:
// Specify the minimum trace level you want to see
Cassandra.Diagnostics.CassandraTraceSwitch.Level = TraceLevel.Info;
// Add a standard .NET trace listener
Trace.Listeners.Add(new ConsoleTraceListener());
答案 1 :(得分:1)
我认为,当您的Cassandra群集位于NAT设备(如防火墙或网关)后面时,了解broadcast_address
和broadcast_rpc_address
的含义非常重要。
broadcast_address
是其他节点连接的地址。默认情况下,这与listen_address
相同(通常您希望这样,因为节点位于同一网络中)。
如果您的群集跨越两个网络并且发生NAT,则必须将其设置为两个网络上的节点都可以访问的值(如果您在AWS中执行多区域部署,则为公共IP)。这意味着网络内部以及网络之间的流量将通过NAT设备,因为内部IP无法访问。
broadcast_rpc_address
是节点“广告”另一个节点的地址。
例如,节点A的broadcast_address
= 10.0.0.100且broadcast_rpc_address
= 52.2.3.100,节点B的broadcast_address
= 10.0.0.101且broadcast_rpc_address
= 52.2.3.101
然后发生的是节点A将连接到10.0.0.101上的节点B,但是如果客户端驱动程序询问A“嘿,群集中有哪些其他节点?”,那么它将响应B的52.2.3.101。
这种设计(我相信在Cassandra 2.0.10中引入)使网络外的客户端可以连接到集群中的任何节点(而不仅仅是种子节点)。
但是一个限制是你不能在网络内外都有客户端,否则你需要确保公共IP在网络内外都可以访问(比如更改防火墙设置)。
我希望这会澄清一些事情。
如果您热衷于此,可以使用以下cqlsh
命令找到节点对其他节点的了解:
select * from system.peers
peer
列是节点的broadcast_address
,rpc_address
列是节点的broadcast_rpc_address
。