1. 首页
  2. 问答
  3. Elasticsearch集群健康VS猫分配IP地址

Elasticsearch集群健康VS猫分配IP地址

2015-09-15 35 views
1

当我做_cluster/health我获得以下（简称为清楚起见）：Elasticsearch集群健康VS猫分配IP地址

"nodes": { 
    "0KSzdqFERwaOyuqZ4oJwMA": { 
     "name": "Index3", 
     "transport_address": "inet[/172.16.120.113:9300]", 
     "attributes": {} 
    }, 
    "IkaQ9UOXRpqnvdnkQLXVAA": { 
     "name": "Index4", 
     "transport_address": "inet[/172.16.120.114:9300]", 
     "attributes": {} 
    } 
}

现在，当我添加第三个节点，_cluster/health这个样子的：

"nodes": { 
    "0KSzdqFERwaOyuqZ4oJwMA": { 
     "name": "Index3", 
     "transport_address": "inet[/172.16.120.113:9300]", 
     "attributes": {} 
    }, 
    "IkaQ9UOXRpqnvdnkQLXVAA": { 
     "name": "Index4", 
     "transport_address": "inet[/172.16.120.114:9300]", 
     "attributes": {} 
    }, 
    "U_XMvuwNTDqspzYAJlEm4w": { 
     "name": "Index5", 
     "transport_address": "inet[/172.16.120.115:9300]", 
     "attributes": {} 
    } 
}

但是当我做_cat/allocation我看到以下内容：

27 42.3gb 17.6gb 59.9gb 70 INDEX3 172.16.120.113 Index3 
27 39.3gb 20.6gb 59.9gb 65 INDEX4 172.16.120.114 Index4 
27 39.5gb 20.4gb 59.9gb 67 INDEX5 169.254.20.178 Index5

而在_cat/shards下，Index3正在试图将一些分片移动到该地址上的Index5节点处并停留在那里。 _cluster/health显示集群是绿色的，但碎片重新分配从未完成。

我已尝试设置network.host但问题仍然存在：

network.host: 172.16.120.115

有人能解释其中/为什么/如何发生这种情况？如何/为什么_cat\allocation捡起169.254.20.178？

安装程序使用elasticsearch 1.1.1在Windows Server 2008R2上运行。

更新1

这里是ipconfig /all：

Windows IP Configuration 

    Host Name . . . . . . . . . . . . : SOMEHOSTNAME 
    Primary Dns Suffix . . . . . . . : dfw.intensive.int 
    Node Type . . . . . . . . . . . . : Hybrid 
    IP Routing Enabled. . . . . . . . : No 
    WINS Proxy Enabled. . . . . . . . : No 
    DNS Suffix Search List. . . . . . : dfw.intensive.int 
             intensive.int 
             sat.intensive.int 
             iad.intensive.int 
             ord.intensive.int 
             lon.intensive.int 
             hkg.intensive.int 
             syd.intensive.int 

Ethernet adapter Local Area Connection* 9: 

    Connection-specific DNS Suffix . : 
    Description . . . . . . . . . . . : Microsoft Failover Cluster Virtual Adapter 
    Physical Address. . . . . . . . . : 7A-2B-CB-33-9B-BB 
    DHCP Enabled. . . . . . . . . . . : No 
    Autoconfiguration Enabled . . . . : Yes 
    Link-local IPv6 Address . . . . . : fe80::782b:cbff:fe33:9bbb%16(Preferred) 
    IPv4 Address. . . . . . . . . . . : 169.254.20.178(Preferred) 
    Subnet Mask . . . . . . . . . . . : 255.255.0.0 
    Default Gateway . . . . . . . . . : 
    DHCPv6 IAID . . . . . . . . . . . : 460991435 
    DHCPv6 Client DUID. . . . . . . . : 00-01-00-01-19-95-67-50-78-2B-CB-33-9B-BF 
    DNS Servers . . . . . . . . . . . : fec0:0:0:ffff::1%1 
             fec0:0:0:ffff::2%1 
             fec0:0:0:ffff::3%1 
    NetBIOS over Tcpip. . . . . . . . : Enabled 

Ethernet adapter PublicNetTeam: 

    Connection-specific DNS Suffix . : 
    Description . . . . . . . . . . . : BASP Virtual Adapter 
    Physical Address. . . . . . . . . : 78-2B-CB-33-9B-BB 
    DHCP Enabled. . . . . . . . . . . : No 
    Autoconfiguration Enabled . . . . : Yes 
    IPv4 Address. . . . . . . . . . . : 172.16.120.219(Preferred) 
    Subnet Mask . . . . . . . . . . . : 255.255.255.0 
    Default Gateway . . . . . . . . . : 172.16.120.1 
    DNS Servers . . . . . . . . . . . : >>MASKED<< 
             >>MASKED<< 
    NetBIOS over Tcpip. . . . . . . . : Enabled 

Ethernet adapter BackupNet: 

    Connection-specific DNS Suffix . : 
    Description . . . . . . . . . . . : Broadcom BCM5709C NetXtreme II GigE (NDIS VBD Client) #33 
    Physical Address. . . . . . . . . : 78-2B-CB-33-9B-BF 
    DHCP Enabled. . . . . . . . . . . : No 
    Autoconfiguration Enabled . . . . : Yes 
    IPv4 Address. . . . . . . . . . . : 10.241.216.69(Preferred) 
    Subnet Mask . . . . . . . . . . . : 255.255.255.224 
    Default Gateway . . . . . . . . . : 
    NetBIOS over Tcpip. . . . . . . . : Disabled 

Ethernet adapter Heartbeat2: 

    Connection-specific DNS Suffix . : 
    Description . . . . . . . . . . . : Broadcom BCM5709C NetXtreme II GigE (NDIS VBD Client) #34 
    Physical Address. . . . . . . . . : 78-2B-CB-33-9B-C1 
    DHCP Enabled. . . . . . . . . . . : No 
    Autoconfiguration Enabled . . . . : Yes 
    IPv4 Address. . . . . . . . . . . : 10.10.10.4(Preferred) 
    Subnet Mask . . . . . . . . . . . : 255.255.255.0 
    Default Gateway . . . . . . . . . : 
    NetBIOS over Tcpip. . . . . . . . : Disabled

而且从elasticsearch.log信息时，节点启动。正如你可以看到它在172.16.120.115上有约束力。

[2015-09-15 15:12:58,510][INFO ][node      ] [Index5] version[1.1.1], pid[2436], build[f1585f0/2014-04-16T14:27:12Z] 
[2015-09-15 15:12:58,510][INFO ][node      ] [Index5] initializing ... 
[2015-09-15 15:12:58,526][INFO ][plugins     ] [Index5] loaded [], sites [] 
[2015-09-15 15:13:02,395][INFO ][node      ] [Index5] initialized 
[2015-09-15 15:13:02,395][INFO ][node      ] [Index5] starting ... 
[2015-09-15 15:13:03,362][INFO ][transport    ] [Index5] bound_address {inet[/172.16.120.115:9300]}, publish_address {inet[/172.16.120.115:9300]} 
[2015-09-15 15:13:07,060][INFO ][cluster.service   ] [Index5] detected_master [Index4][IkaQ9UOXRpqnvdnkQLXVAA][647264-INDEX4][inet[/172.16.120.114:9300]], added {[Index3][0KSzdqFERwaOyuqZ4oJwMA][INDEX3][inet[/172.16.120.113:9300]],[Index4][IkaQ9UOXRpqnvdnkQLXVAA][INDEX4][inet[/172.16.120.114:9300]],}, reason: zen-disco-receive(from master [[Index4][IkaQ9UOXRpqnvdnkQLXVAA][INDEX4][inet[/172.16.120.114:9300]]]) 
[2015-09-15 15:13:07,278][INFO ][discovery    ] [Index5] elasticsearch/U_XMvuwNTDqspzYAJlEm4w 
[2015-09-15 15:13:08,152][INFO ][http      ] [Index5] bound_address {inet[/172.16.120.115:9200]}, publish_address {inet[/172.16.120.115:9200]} 
[2015-09-15 15:13:08,152][INFO ][node      ] [Index5] started

什么是令人难以置信的是，我可以在发出请求http://172.16.120.115:9200，我得到的反应回来，但也不碎片重新分配模块似乎变得local link IP。

curl http://172.16.120.115:9200/_cluster/health?pretty 
{ 
    "cluster_name": "elasticsearch", 
    "status": "green", 
    "timed_out": false, 
    "number_of_nodes": 3, 
    "number_of_data_nodes": 3, 
    "active_primary_shards": 27, 
    "active_shards": 54, 
    "relocating_shards": 2, 
    "initializing_shards": 0, 
    "unassigned_shards": 0 
} 

curl http://172.16.120.115:9200/_cat/shards 
logindex_r210  1 r RELOCATING 240670 104.2mb 172.16.120.114 Index4 -> 169.254.20.178 Index5 
logindex_r210  1 p STARTED  240670 104.2mb 172.16.120.113 Index3      
logindex_r210  2 p STARTED  240747 106.4mb 172.16.120.114 Index4      
logindex_r210  2 r STARTED  240747 106.4mb 172.16.120.113 Index3      
companyindex_r210 4 p STARTED  394869 52.6mb 172.16.120.114 Index4      
companyindex_r210 4 r STARTED  394869 52.6mb 172.16.120.113 Index3      
companyindex_r210 0 p STARTED  395000 62.6mb 172.16.120.114 Index4      
companyindex_r210 0 r RELOCATING 395000 52.7mb 172.16.120.113 Index3 -> 169.254.20.178 Index5

来源

2015-09-15 CrnaStena

回答

1

169.254.0.0范围内的IP地址是标准的“本地链接”块。如RFC3927中所述，它被分配用于单个链路上主机之间的通信。主机通过自动配置获取这些地址，例如无法找到DHCP服务器时。

所以它看起来像你的节点有1）没有配置静态IP地址和2）无法从DHCP服务器获得一个，所以它构成了它自己在169.254范围内的IP地址，因此它可以通信网络。

您可能想要解决这个问题，以便您的分片分配继续进行。您的节点无法获得IP地址的事实很可能是重新定位停滞的原因。

来源

2015-09-16 03:15:30 Val

+0

我完全同意你@Val。我添加了其他信息。节点绑定在合适的地址并返回信息等，但是执行碎片重定路由/重新分配的elasticsearch模块正在获得'链路本地'IP。 – CrnaStena

相关问题

 相关问题