1. 首頁
  2. 問答
  3. Elasticsearch集羣健康VS貓分配IP地址

Elasticsearch集羣健康VS貓分配IP地址

2015-09-15 37 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

相關問題

 相關問題