如何配置集群的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也停止了。

当前集群状态如下图：