![Juju LXC 容器获取了错误的 DHCP?](https://linux22.com/image/987617/Juju%20LXC%20%E5%AE%B9%E5%99%A8%E8%8E%B7%E5%8F%96%E4%BA%86%E9%94%99%E8%AF%AF%E7%9A%84%20DHCP%EF%BC%9F.png)
我正在使用与此类似的网络: http://www.openstackbasement.com/maas-network-hardware
当我跑步时:
juju 部署——到 lxc:0 mysql juju 部署——到 lxc:0 keystone 等...
根据 Marco 的指示:http://marcoceppi.com/2014/06/deploying-openstack-with-just-two-machines/
我的 LXC 机器最终在错误的网络 (192.168.1.0) 上通过 DHCP 启动,而不是 (10.207.39.0)。juju-br0 上的 ip 是 10.207.39.2,所以我很惊讶 LXC 容器通过 DHCP 获得了 192.168.1.x IP。
最终结果是容器永远处于待处理状态,例如:
服务:cinder:charm:cs:trusty/cinder-34 暴露:false 服务状态:当前:未知 消息:正在等待代理初始化完成 自:2016 年 2 月 2 日 13:33:00-06:00 关系:集群:-cinder 单位:cinder/0:工作负载状态:当前:未知 消息:正在等待代理初始化完成 自:2016 年 2 月 2 日 13:33:00-06:00 代理状态:当前:分配 自:2016 年 2 月 2 日 13:33:00-06:00 代理状态:待定 机器:0/lxc/6
我如何让 LXC 容器从 MAAS dhcp/dns 获取 DHCP?请注意,物理节点(Dell PowerEdge 2850)可以正常获取 IP 地址,并且位于 MAAS DNS/DHCP 中:
从 maas 控制器服务器查找:
orabuntu@maas1:~$ nslookup outrageous-sneeze 服务器:10.207.39.100 地址:10.207.39.100#53
姓名:outrageous-sneeze.maas 地址:10.207.39.2
orabuntu@maas1:~$
从 outrageous-sneeze 本身查找:
ubuntu@outrageous-sneeze:~$ nslookup outrageous-sneeze 服务器:10.207.39.100 地址:10.207.39.100#53
姓名:outrageous-sneeze.maas 地址:10.207.39.2
ubuntu@outrageous-sneeze:~$
我已经尝试了 /etc/network/interfaces.d/eth0.cfg、/etc/network/interfaces、/etc/dhcp/dhclient.conf 中的各种设置,以使 resolv.conf 能够使用
名称服务器 10.207.39.100 搜索 maas
ubuntu@outrageous-sneeze:~$ cat /etc/resolv.conf hash 由 hash resolvconf(8) 生成的用于 glibc resolver(3) 的动态 resolv.conf(5) 文件 请勿手动编辑此文件 - 您的更改将被覆盖 nameserver 10.207.39.100 search maas ubuntu@outrageous-sneeze:~$
但是所有 LXC 容器不断获取 192.168.1.x dhcp 地址,我很确定它们应该在 10.207.39.x 网络上才能正常工作,这就是它们卡住并且无法完成部署的原因。
谢谢,吉尔伯特
答案1
所以我最终自己解决了这些问题,如果这对其他人有帮助,我会在这里发布我的步骤。我让它完美地工作,但它需要对我的设置进行一些调整,我将在这里分享,以防它对其他人有帮助。我上面问的名义问题是如何让 LXC 容器出现在 MAAS LAN DHCP(10.207.39.0/24)网络上,而不是 ROUTER WAN DHCP(192.168.1.0/24)网络上。
经过多次反复尝试后,显然我找不到这样做的方法,也没有找到答复,所以我继续研究如何让我的 OpenStack 工作,让 LXC 容器出现在它们首选的 WAN 网络上。
在这种情况下,我遇到的问题是部署到 LXC 容器的 Juju Charms 在 Juju GUI 中始终处于“待处理”状态,当然在“juju 状态”中也是相同的状态。我希望我已经掌握了完全修复此待处理状态问题所需的所有步骤。如果我遗漏了任何内容,我会在这里更新,希望这对其他人有所帮助。
基本策略是在开始部署 LXC 容器之前对 /var/lib/lxc/juju-trusty-lxc-template/rootfs 文件系统中的几个文件进行这些编辑。这些编辑将在所有后续部署的容器中全局生效。只需在以下内容中替换您的接口名称和 LAN 网络,它就可以正常工作。
我的 maas 服务器设置是:
Dell PowerEdge 2850,BIOS 为最新 A07 版本,以及 Dell BMC 固件,v.1.83,A10(这些 BIOS 和固件升级是必需的)
maas 服务器上的 15.10 ubuntu 服务器版本;所有登记的裸机节点均使用来自 maas 的 14.04 可信映像。2
x 1Gb 网络端口
enp6s7 192.168.1.37 静态 IP
enp7s8 10.207.39.100 静态 IP
我的 maas 登记裸机也是 Dell PowerEdge 2850。Dell BMC IPMI 设置为 DHCP,并在 192.168.1.0/24 网络上获取地址,裸机 maas 登记节点出现在 10.207.39.0/24 网络上。
调整 1:由于我使用两个网络,我需要通过 192.168.1.0/24 上的 WAN 路由 10.207.39.0/24 网络,以便能够通过“互联网”从外部世界下载到 maas 登记的裸机 LXC 主机。这可以通过向 maas 服务器添加以下规则来实现:
sudo iptables -A FORWARD -s 10.207.39.0/24 -o enp6s7 -j ACCEPT
sudo iptables -A FORWARD -d 10.207.39.0/24 -m state --state ESTABLISHED,RELATED -i enp6s7 -j ACCEPT
sudo iptables -t nat -A POSTROUTING -s 10.207.39.0/24 -o enp6s7 -j MASQUERADE
sudo iptables-save | sudo tee /etc/iptables.sav
一旦设置了上述规则,就应该可以从 10.207.39.0/24 网络上的 maas 列出的裸机 LXC 主机“nslookup google.com”和“ping -c 3 google.com”。
注 1:这里,enp6s7 是 192.168.1.0/24 网络上 maas 服务器上的“互联网连接”接口(即连接到我的宽带互联网服务提供商提供的路由器),10.207.39.0/24 是 enp7s8 接口上的私有 LAN 网络,是 maas 及其 maas 列出的裸机服务器使用的网络。
注意 2:通过在 /etc/rc.local 中的“exit 0”行之前添加以下行,规则将在 maas 服务器重启后永久生效,如下所示:
sudo iptables-restore < /etc/iptables.sav
exit 0
注意 3:检查 maas 服务器重启后规则是否应用,如下所示:gstanden@ubuntu:~$ sudo iptables -S
-P 输入接受
-P 转发接受
-P 输出接受
-A 转发 -s 10.207.39.0/24 -o enp6s7 -j 接受
-A 转发 -d 10.207.39.0/24 -i enp6s7 -m 状态 --state 相关,已建立 -j 接受
gstanden@ubuntu:~$
调整 2:在 MAAS 服务器上启用 DNS 查找。使用 /etc/network/interfaces(因为我尝试使用 /etc/dhcp/dhclient.conf 执行此操作,但不起作用),但使用 /etc/network/interfaces 可以。添加“dns-nameservers”和“dns-search”条目,如下所示。请注意,我发现它们应该添加到 enp6s7 规范中;添加到 enp7s8 规范对我来说不起作用。
gstanden@ubuntu:~$ cat /etc/network/interfaces (注释) 此文件描述了系统上可用的网络接口 (注释) 以及如何激活它们。有关更多信息,请参阅interfaces(5)。
源 /etc/network/interfaces.d/*
(注释)环回网络接口
自动 lo
iface lo inet loopback
(评论)主网络接口
自动 enp6s7
iface enp6s7 inet 静态
地址 192.168.1.37
网络 192.168.1.0
网络掩码 255.255.255.0
网关 192.168.1.1
广播 192.168.1.255
dns-search maas<-- 添加此条目
dns 名称服务器 10.207.39.100 <-- 添加此条目
(评论)MAAS 网络接口
自动 enp7s8
iface enp7s8 inet 静态
地址 10.207.39.100
网络 10.207.39.0
网络掩码 255.255.255.0
网关 10.207.39.100
广播 10.207.39.255
gstanden@ubuntu:~$
maas 服务器上还需要进行另外一项调整:在 maas 控制器服务器(而不是 lxc 裸机主机)上编辑 /etc/sysctl.conf,使得以下命令给出如下所示的结果:
gstanden@ubuntu:~$ sudo sysctl -p
net.ipv4.ip_forward = 1
gstanden@ubuntu:~$
注 1:这将允许属于此 maas 的 10.207.39.0/24 网络中的 maas 节点上的登记裸机服务器的 nslookups 和 ping 运行。
调整 3:需要进行一些调整才能在 LXC 容器内部建立强大的网络服务。对 lxc 模板的这些调整将解决从裸机 lxc 主机下载 juju 工具的问题,并将解决解析 WAN(192.168.1.0/24 地址)的问题,并将解决解析 10.207.39.0/24 网络上的地址的问题。
注 1:遇到的问题是无论如何调整 /var/lib/lxc/machine/config 文件,容器总是会在 192.168.1.0/24 网络上获得一个地址,即使它们使用的是具有 10.207.39.0/24 地址的 juju-br0 网桥!(有趣,是吧?);但是在这个双网络 LAN/WAN 设置中,最终需要的是联网到两个网络,因此在这种情况下使用路由。
调整 3a:ssh ubuntu@portly-legs(portly-legs 是 maas 为我的 maas 裸机 lxc 主机提供的登记名称)
须藤苏-
cd /var/lib/lxc/juju-trusty-lxc-template/rootfs/etc/network/interfaces.d/
vi eth0.cfg 并将以下行添加到 eth0.cfg 文件(添加“up ip route...”和“dns-search maas”行)。
自动 eth0
iface eth0 inet dhcp
up ip 路由通过 192.168.1.37 添加 10.207.39.0/24
dns-search maas
ip route 行将建立从 192.168.1.0/24 上的 lxc 容器(LXC 容器中的 eth0)到 10.207.39.0/24 网络上 maas 列出的裸机 lxc 主机的 ssh / ping / scp 连接等。“dns-search maas”行是 maas DNS 查找如何在 LXC 容器内部可用的部分,以便包括 maas 网络在内的完整 DNS 解析能够正常工作。当 maas 列出的裸机 lxc 主机上的 lxc 容器去获取 juju 工具时,这一点尤其需要 - 这些 lxc 容器将尝试从裸机 lxc 主机(在此示例中,它恰好是 10.207.39.152,即 portly-legs.maas)提取此工具,如果没有此路由,则从 .152 的 lxc 主机提取工具将失败。您可以通过登录 lxc 容器并执行“tail -f /var/log/cloud-init.log”来判断成功/失败,您将看到工具拉取失败或成功。
调整 3b:编辑 /var/lib/lxc/juju-trusty-lxc-template/rootfs/etc/dhcp/dhclient.conf 文件并添加此行(您可以取消注释示例行并修改它):
在域名服务器前面添加 10.207.39.100;
注 1:这可能也可以在 /var/lib/lxc/juju-trusty-lxc-template/rootfs/etc/network/interfaces.d/eth0.cfg 中使用“dns-nameservers 10.207.39.100”条目来完成,但在这种情况下我使用了 dhclient.conf。
我认为这就是所有的调整。一旦完成所有这些调整,就可以开始将 openstack 组件部署到此双网络设置中的 LXC 容器中,它们会像煎饼出炉一样快速地从待处理状态进入就绪状态!如果我遗漏了任何步骤,请告诉我,我也会尝试仔细检查这些步骤。但我认为就是这样。
完成所有这些步骤后,尝试将 openstack 组件部署到 LXC 并监控进度:
(以拥有 maas 部署的用户身份从 maas 服务器上的终端):ssh ubuntu@(容器的 ip 地址)
在容器上:sudo su - 在容器上:tail -f /var/log/cloud-init.log 和/或 tail -f /var/log/cloud-init-output.log
如果你看到这样的消息,那么你可能一切都很好:
尝试 1 从 -ttps://10.207.39.152:17070/tools/1.25.3-trusty-amd64 下载工具... + curl -sSfw 工具从 %{url_effective} 下载:HTTP %{http_code};时间 %{time_total}s;大小 %{size_download} 字节;速度 %{speed_download} 字节/秒 --noproxy * --insecure -o /var/lib/juju/tools/1.25.3-trusty-amd64/tools.tar.gz -ttps://10.207.39.152:17070/tools/1.25.3-trusty-amd64 工具从 -ttps://10.207.39.152:17070/tools/1.25.3-trusty-amd64 下载:HTTP 200;时间 1.698 秒;大小 18722171 字节;速度 11026214.000 字节/秒 + echo 工具下载成功。工具下载成功。
当 LXC 容器中的网络出现问题时,多次尝试都会失败。上述调整应该可以完全解决这些问题,并且还将在 LXC 容器内部提供 maas 网络上裸机 maas 登记服务器的完整 DNS 查找(LXC 主机和单个产品主机,如 nova-compute)。每个容器应在不到 5 分钟的时间内进入完全部署就绪状态。我一次部署一个,然后等待每个容器达到就绪状态。YMMV,HTH,Gilbert Standen,密苏里州圣路易斯,2016 年 2 月 11 日,下午 1:25(中部时间)