如何配置集群的vip

⑴ VirtualBox做第二套oracle集群環境，vip地址ping不通，但第一套集群環境成功搭建，IP地址沒有任何問題

既然是vip，它就是虛擬的，只有cluster資源啟動後才能ping的通啊，也就是cluster安裝完後，它是在public網卡上虛擬出來的，開始安裝前，你只需要手動設置好public和private地址。
信任關系如果手動實在搞不定，可以自動配置

⑵ keepalived+lvs+mysql集群VIPping不通

因為交換機上沒配相關路由吧，跨網段的時候是會存在路由問題的，如果你把VIP也設置為192.168.2.*應該就沒這個問題了。因為其他機器放問192.168.100.100的時候會默認去192.168.100.*的網段去尋找主機，所以就招不到具體的物理地址了。還有個辦法就是在2.x的主機上都配置靜態路由，add route ， 把192.168.100.100的路由配置到192.168.2.254（貌似這個是網關？）建議還是換成2.x的地址更合理。我們一般做地址規劃的時候，200以內都是物理ip，200以上都給VIP預留，就是為了避免這種問題。keepalived+lvs+mysql集群VIPping不通

⑶ oracle vip 怎麼配置

配置在hosts文件裡面。

⑷ 集群的pub scan vip的ip都是什麼意思

R6 IP 為主要的 服務IP Service IP

VIP, Scan IP 為虛擬的IP，這是掛在 服務IP下方的

在 RAC 架構下, 有兩個 node
VIP Virtual IP 就是虛擬的IP，可以隨便起在任何一個node

Scan IP 則是後來為了 做 single client access, 的IP

VIP IP, Scan IP 因為是虛擬的IP，所以都可以隨著硬體狀況在不同的 服務IP下飄移

⑸ k8s 控制平面HA vip LB

首先cluster ip 也能起到vip的作用，同時也具備HA的功能。

當然cluster ip是內部訪問，無法集群外訪問，也就是說只有內部的高可用。

關於metalLB 提供 vip 以及HA的外網訪問方案的討論： https://github.com/metallb/metallb/issues/168

k8s的關於ha vip的建議是必須找一個k8s外的LB才可以，否則就會有循環依賴，一旦LB掛掉，集群將是無法響應的一個狀態。
首先提供一個LB，然後配置給k8s集群用：

比如內網集群的使用方式：
首先基於openstack建一個集群外的LB，然後配置給kubespray用，重新刷新k8s配置

apiserver_loadbalancer_domain_name: "cn-shanghai-on-prem-k8s-lb.yealinkops.com"
loadbalancer_apiserver:
address: 10.120.26.110
port: 6443

可以看到該IP不通時，k8s關鍵服務都會有影響。

如果IAAS層，LB服務也在k8s中管理，那麼其實可以基於LB服務提供該ha IP，但是當然不能給所在k8s集群用。這確實是一個循環依賴。但是k8s控制平面外部都是可以使用該IP的。

小結：
k8s本身具有HA方案，只是k8s控制平面需要提供一個外部vip來供用戶使用，至於k8s本身的控制平面並不依賴該vip，外部vip的有無對HA沒有影響。

⑹ oracle rac 中hosts中為什麼要配置公有IP 、私有IP、 vip 分別都是幹嘛用的

兩個都是服務IP，都可以對外提供服務。關於你說的網頁的說法，是正確的。不過正常來說，既然是集群，像這些網頁信息應該放在共享磁碟上面，不然做集群就沒有意義了。

vip漂移的情況有幾種僅供參考：
1、vip手動切換
2、某一個節點不可用

3、手動執行資源分配

RAC裡面的IP很多，有幾個節點就有幾個VIP。
SCAN_IP如果沒有使用dns以及dhcp伺服器，一般都只有一個。

你說的問題，最好詳細將步驟以及輸出列出來。

⑺ 如何進行Hyper-V集群部署簡化網路配置

當你進行一次Hyper-V集群的部署時，配置網路會是一件痛苦的事情。不同的廠商或變更的硬體布局僅僅是自動化部署所遇挑戰中的兩個舉例。這篇文章中我將和你分享用PowerShell收集信息的方法，這些信息關於哪個網路適配器位於什麼PCI匯流排。你之後可以使用這些信息來重命名網路適配器，組合、更改網路適配器設置等等。
我們首先從收集現有網路適配器的信息開始。完成該過程的PowerShell命令如下：
Get-WMIObject Win32_PNPSignedDriver where { $_.DeviceClass -eq 「NET」 -and
$_.HardWareID -like 「*PCI*」}
結果如下圖所示：
在輸出中我們發現網路適配器的位置。你可能會想，如果伺服器上有12個網路適配器，那麼它就不實用了。那麼我們就能過在這條PowerShell命令中加入
ft Location來收集PCI匯流排信息。
Get-WMIObject Win32_PNPSignedDriver where { $_.DeviceClass -eq 「NET」 -and
$_.HardWareID -like 「*PCI*」} ft Location
現在我們擁有所有伺服器中網路適配器的位置了，但是哪個是哪個呢？
我們需要的是適配器名稱，比如任務管理器。下面的命令會讓你得到這些信息。同樣對於所有適配器，它就有些不適用了。
Get-WMIObject Win32_NetworkAdapter where { $_.PNPDeviceID -eq
$Adapter.DeviceID }
讓我們將第一條命令放入變數中並且對第二條命令做一個循環。要顯示結果，我們做一個簡單的Write-Host來顯示輸出。接著腳本會顯示如下：
$Adapters = Get-WMIObject Win32_PNPSignedDriver where { $_.DeviceClass
-eq 「NET」 -and $_.HardWareID -like 「*PCI*」}
foreach （$Adapter in $Adapters ） {
$AdapterName = Get-WMIObject Win32_NetworkAdapter where { $_.PNPDeviceID
-eq $Adapter.DeviceID }
Write-Host 'Adapter Name :' $AdapterName.NetConnectionID
Write-Host 'PCI BUS :' $Adapter.Location
Write-Host 'MAC Address :' $AdapterName.MACAddress
Write-Host 'GUID :' $AdapterName.GUID
Write-Host
}
就是這樣子。我還添加了MAC地址和GUID。這個實例的MAC地址還和博通的BACScli.exe命令行工具聯合使用，用來配置網路適配器設置。如果需要，GUID可以用來添加TcpAckFrequency到注冊表。
復制粘貼會確保所有單雙引號都正確。希望這篇文章能對你有用。
轉載僅供參考，版權屬於原作者。祝你愉快，滿意請採納哦

⑻ 快速搭建kubernetes高可用集群（3master+3worker+負載均衡）

kubeadm 是Kubernetes官方提供的用於快速安裝Kubernetes集群的工具，通過kubeadm的方式安裝集群比二進制的方式安裝高效不少。建議初次使用k8s使用此方式安裝，二進制的方式會很快令人失去信心。

在開始之前，部署Kubernetes集群機器需要滿足以下幾個條件：

dnsmasq安裝可參考我的另一篇 文章

ha1節點配置

ha2節點配置

在兩台ha節點都執行

啟動後查看ha的網卡信息（有一台可看到vip）

兩台ha節點的配置均相同，配置中聲明了後端代理的兩個master節點伺服器，指定了haproxy運行的埠為16443等，因此16443埠為集群的入口

兩台ha都啟動

檢查埠

Kubernetes默認CRI（容器運行時）為Docker，因此先安裝Docker。kubelet控制容器，kubeadm控制加入平面。

鏡像加速

由於版本更新頻繁，這里指定版本號部署：

在master1操作

按照提示配置環境變數，使用kubectl工具：

按照提示保存以下內容，一會要使用：

查看集群狀態

從官方地址獲取到flannel的yaml，在master1上執行

安裝flannel網路

檢查

從master1復制密鑰及相關文件到master2

master3操作同上

執行在master1上init後輸出的join命令,需要帶上參數 --control-plane 表示把master控制節點加入集群

檢查狀態

在node1、2、3上執行

向集群添加新節點，執行在kubeadm init輸出的kubeadm join命令：

檢查狀態

在Kubernetes集群中創建一個pod，驗證是否正常運行：

訪問地址： http://NodeIP:Port

⑼ 負載均衡——LVS DR模式

相比於nginx只能用於7層負載均衡，LVS就比較強大了，能在4層做負載均衡。而且性能和穩定性上LVS也比較占優，畢竟是合入內核模塊，不穩定肯定不行。

LVS通過工作於內核的ipvs模塊來實現功能，其主要工作於netfilter的INPUT鏈上。除此之外，還需要一個用戶態工具，ipvdadm，用於用戶負載集群定義和集群服務管理。

LVS DR模式的流程大概如下：

1、客戶端發送請求至VIP，也就是訪問服務，請求報文源地址是CIP，目標地址為VIP；

2、LVS調度器接收到請求，報文在PREROUTING鏈檢查，確定目的IP是本機，於是將報文發送至INPUT鏈，ipvs內核模塊確定請求的服務是我們配置的LVS集群服務，然後根據用戶設定的均衡策略選擇某台後端RS，並將目標MAC地址修改RIP的MAC地址。因為調度器和後端伺服器RS在同個網段，因此直接二層互通，將請求發給選擇的RS處理；

3、因為報文目的mac是本機，且RS上有配置VIP，因此RS能接收該報文。後端服務處理完請求後，將響應直接發往客戶端，此時源IP地址為VIP，目標IP為CIP。

如下，准備三台伺服器，

機器 作用

192.168.0.100 VIP，LVS調度器對外服務IP

192.168.0.200 RIP，後端web伺服器之一

192.168.0.300 RIP，後端web伺服器之二

上面我們說過lvs依賴於ipvs內核模塊，和ipvsadm用戶態工具。因為centos 7已經默認載入ipvs模塊，因此這一步我們不需要配置。我們只需要安裝ipvsadm工具即可，

yum install -y ipvsadm

然後在LVS調度器上配置VIP，這里我們採用虛擬網卡，當然也可以使用獨立網卡配置，

ifconfig eth0:0 192.168.0.100/24 up

接著配置LVS集群服務，

[root@CentOS-7-2 ~]# ipvsadm -C

[root@CentOS-7-2 ~]# ipvsadm -A -t 192.168.0.100:80 -s rr

[root@CentOS-7-2 ~]# ipvsadm -a -t 192.168.0.100:80 -r 192.168.0.200:80 -g

[root@CentOS-7-2 ~]# ipvsadm -a -t 192.168.0.100:80 -r 192.168.0.300:80 -g

其中，

第一條命令是清空所有規則；

第二條命令是定義LVS服務，並指定負責均衡策略為rr，即輪詢；

第三、四條命令各添加一台後端web伺服器，作為負載均衡節點，並指定為DR模式。

ipvsadm基本命令參數如下：

-A  指定添加的LVS負載均衡虛擬服務

-t  指定虛擬伺服器的IP地址和埠

-s  指定調度演算法，ss為輪詢，wrr為加權輪詢，dh為目標地址散列，sh為源地址散列，lc為最少鏈接等

-a  在對應的VIP下添加RS節點

-g  指定LVS的工作模式為DR模式

-l  指定LVS的工作模式為tunnel模式

-m  指定LVS的工作模式為NAT模式

添加完後端RS，我們可以查看此LVS對應的均衡規則，

[root@CentOS-7-2 ~]# ipvsadm -Ln

IP Virtual Server version 1.2.1 (size=4096)

Prot LocalAddress:Port Scheler Flags

  -> RemoteAddress:Port          Forward Weight ActiveConn InActConn

TCP  192.168.0.100:80 rr

  -> 192.168.0.200:80            Route  1      0          0       

  -> 192.168.0.300:80            Route  1      0          0

這里web伺服器使用nginx搭建，因此在兩台RS上安裝nginx，

yum install -y nginx

同時為了後面測試，我們修改web伺服器的index.html內容，

[root@192_168_0_200 ~]# cat /usr/share/nginx/html/index.html

This is 192.168.0.200

[root@192_168_0_300 ~]# cat /usr/share/nginx/html/index.html

This is 192.168.0.300

接著開始進行LVS相關配置，

首先將VIP配置在lo介面上，(注意掩碼要配置成32位，不然RS通信會出問題)

ifconfig lo:0 192.168.0.100/32 up

接著配置對應路由，

route add -host 192.168.0.100 dev lo

然後設置相關系統參數，

echo 1 > /proc/sys/net/ipv4/conf/eth0/arp_ignore

echo 2 > /proc/sys/net/ipv4/conf/eth0/arp_announce

echo 1 > /proc/sys/net/ipv4/conf/all/arp_ignore

echo 2 > /proc/sys/net/ipv4/conf/all/arp_announce

其實嚴格意義上只要配置出口網卡的對應參數就可以了，配置all也只是為了保險而已，文章最後面會有說明。

使用curl命令對vip進行訪問，

[root@CentOS-7-3 /home]# curl  http://192.168.0.100:80

This is 192.168.0.200

[root@CentOS-7-3 /home]# curl  http://192.168.0.100:80

This is 192.168.0.300

[root@CentOS-7-3 /home]# curl  http://192.168.0.100:80

This is 192.168.0.200

[root@CentOS-7-3 /home]# curl  http://192.168.0.100:80

This is 192.168.0.300

可見結果符合我們設置的輪詢策略。

因為當調度器把請求轉發給對應RS時，並沒有修改報文目的IP，因此請求報文目的IP仍為VIP，所以如果RS沒有配置VIP，那麼報文到達RS後就會被丟棄。

arp_ignore=1:只響應目的IP地址為接收網卡上的本地地址的arp請求

因為我們在RS上都配置了VIP，因此此時是存在IP沖突的，當外部客戶端向VIP發起請求時，會先發送arp請求，此時調度器和RS都會響應這個請求。如果某個RS響應了這個請求，則之後該客戶端的請求就都發往該RS，並沒有經過LVS，因此也就沒有真正的負載均衡，LVS也就沒有存在的意義。因此我們需要設置RS不響應對VIP的arp請求，這樣外部客戶端的所有對VIP的arp請求才會都解析到調度器上，然後經由LVS的調度器發往各個RS。

系統默認arp_ignore=0，表示響應任意網卡上接收到的對本機IP地址的arp請求(包括環回網卡上的地址)，而不管該目的IP是否在接收網卡上。也就是說，如果機器上有兩個網卡設備A和B，即使在A網卡上收到對B IP的arp請求，也會回應。而arp_ignore設置成1，則不會對B IP的arp請求進行回應。由於lo肯定不會對外通信，所以如果只有一個對外網口，其實只要設置這個對外網口即可，不過為了保險，很多時候都對all也進行設置。

arp_announce=2:網卡在發送arp請求時使用出口網卡IP作為源IP

當RS處理完請求，想要將響應發回給客戶端，此時想要獲取目的IP對應的目的MAC地址，那麼就要發送arp請求。arp請求的目的IP就是想要獲取MAC地址的IP，那arp請求的源IP呢？自然而然想到的是響應報文的源IP地址，但也不是一定是這樣，arp請求的源IP是可以選擇的，而arp_announce的作用正是控制這個地址如何選擇。系統默認arp_announce=0，也就是源ip可以隨意選擇。這就會導致一個問題，如果發送arp請求時使用的是其他網口的IP，達到網路後，其他機器接收到這個請求就會更新這個IP的mac地址，而實際上並不該更新，因此為了避免arp表的混亂，我們需要將arp請求的源ip限制為出口網卡ip，因此需要設置arp_announce=2。

由上可知，只要RS上的VIP不響應arp請求就可以了，因此不一定要配置在lo上，也可以配置在其他網口。由於lo設備不會直接接收外部請求，因此只要設置機器上的出口網卡不響應非本網卡上的arp請求介面。但是如果VIP配置在其他網口上，除了上面的配置，還需要配置該網口不響應任何arp請求，也就是arp_ignore要設置為8。

這是由於lo設備的特殊性導致， 如果lo綁定192.168.0.200/24，則該設備會響應該網段所有IP(192.168.0.1~192.168.0.254) 的請求，而不是只響應192.168.0.200這一個地址。

根據DR模式的原理，調度器只修改請求報文的目的mac，也就是轉發是在二層進行，因此調度器和RS需要在同一個網段，從而ip_forward也不需要開啟。

⑽ Linux HA 集群原理和配置-02

本文介紹在Linux HA集群中的仲裁和分區概念。

集群正常工作時，所有節點都在一個分區內（partition），分區內的所有節點將選舉出一個仲裁節點，這個仲裁節點負責向其他節點發送集群控制命令。當網路發生故障時，集群中的節點發現無法和仲裁節點通信，則會在可通信的范圍內重新選舉一個新的仲裁節點。此時集群內可能出現多個仲裁節點，每個仲裁節點的管理范圍為一個分區。

下文中將通過防火牆策略的設置模擬集群網路中通信出現異常的各種情況，如：

通過防火牆策略可以精準控制兩兩節點之間的連通性，使我們能更准確的了解在網路連通性發生變化對集群的影響。

在所有節點上啟動防火牆，並添加策略對整個管理網路192.168.56.0/24放通。

保存上述策略，之後在實驗過程會使用iptables命名加入新策略模擬網路通信異常效果，如果需要恢復網路通信正常狀態，直接不保存策略重啟firewalld服務即可。

通過pcs status查看集群狀態：

上述結果顯示當前集群只有一個分區，分區內的節點包括全部3台主機，仲裁節點是ha-host3，這表示集群間的通信是完好的。下圖顯示當前集群狀態：

在ha-host1上添加以下策略：

該策略將使得ha-host1和ha-host3之間的通信中斷，在所有節點上查看集群狀態：

上面的結果顯示，ha-host1失去和當前仲裁節點ha-host3的聯系之後，和ha-host2一起組成新的分區並選舉出ha-host2作為新的仲裁節點。有趣的是ha-host2和ha-host3的通信並未中斷，但是他被「優先順序較高的ha-host1搶走並推舉為老大」，剩下ha-host3獨自留在其自身所在的分區。此時ha-host3所在的分區提示了「partition WITHOUT quorum」，表示該分區中的節點數目不超過一半。

下圖顯示當前集群狀態：

在ha-host1上再添加策略：

使其和當前的仲裁節點ha-host2的通信中斷，集群狀態變為：

發現ha-host2和ha-host3一起組成了新的分區，由於ha-host1所在分區節點數不足一半，無法啟動資源，虛擬ip資源vip被切換到了ha-host2上。下圖顯示當前集群狀態：

如果再把ha-host2和ha-host3直接的通信中斷，此時3個節點間兩兩均無法通信。每個節點都是一個分區，每個分區的主機數均不過半，因此無法啟動任何資源，原先運行在ha-host2上的vip也停止了。

當前集群狀態如下圖：