<div dir="ltr">Hello Eugen,<div>I got it know. </div><div><br></div><div>Thank you very much. </div><div><br></div><div><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr">Nguyen Huu Khoi<br></div></div></div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Aug 13, 2023 at 3:09 PM Eugen Block <<a href="mailto:eblock@nde.ag">eblock@nde.ag</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Which part is unclear? I added [1] where the physical network  <br>
structure is explained a bit.<br>
The major advantage of using provider networks is that the compute  <br>
nodes are themselves physically attached to the external (provider)  <br>
network, so VM traffic doesn't have to be routed across  <br>
control/network nodes. That mitigates a potential bottleneck if for  <br>
example you only have on control node, lots of VMs and all of them  <br>
send their traffic through that one control node. Spreading that load  <br>
out across the compute nodes reduces the load on the control node(s).<br>
So if our control nodes fail the VMs in the provider networks are not  <br>
affected.<br>
Apart from that, if your DHCP agents misbehave I definitely would look  <br>
into that and fix it, independent of provider networks. The logs might  <br>
reveal something, for example if the agents are overloaded. We saw  <br>
that last year in a customer cloud where only one agent was available  <br>
due to power outage on the second control node (third one was in  <br>
maintenance). We also increased "dhcp_agents_per_network" to 2  <br>
(default 1) which seems to have helped there as well. We haven't had  <br>
any issues since then.<br>
<br>
[1]  <br>
<a href="https://docs.openstack.org/install-guide/launch-instance-networks-provider.html" rel="noreferrer" target="_blank">https://docs.openstack.org/install-guide/launch-instance-networks-provider.html</a><br>
<br>
Zitat von Nguyễn Hữu Khôi <<a href="mailto:nguyenhuukhoinw@gmail.com" target="_blank">nguyenhuukhoinw@gmail.com</a>>:<br>
<br>
> Hello Eugen,<br>
><br>
> I got what you mean, but "So as long as the compute nodes<br>
> and the network infrastructure are running we can work, the less<br>
> important VMs are not reachable during that time, of course, but it<br>
> doesn't really hurt anybody."<br>
><br>
> Can you explain this to me?<br>
><br>
> Nguyen Huu Khoi<br>
><br>
><br>
> On Sun, Aug 13, 2023 at 1:13 AM Eugen Block <<a href="mailto:eblock@nde.ag" target="_blank">eblock@nde.ag</a>> wrote:<br>
><br>
>> That's depending on your use-case. We have two types of VMs in our<br>
>> cloud, production VMs and the rest (self-service tenant networks). All<br>
>> production VMs are in provider networks, launched with config-drive<br>
>> and independent of the control plane. So as long as the compute nodes<br>
>> and the network infrastructure are running we can work, the less<br>
>> important VMs are not reachable during that time, of course, but it<br>
>> doesn't really hurt anybody.<br>
>> So if you have machines that are required to work independent of<br>
>> network nodes (control nodes) you should consider using such provider<br>
>> networks. Or move the VMs to those networks if you already have been<br>
>> using provider networks.<br>
>><br>
>> Zitat von Nguyễn Hữu Khôi <<a href="mailto:nguyenhuukhoinw@gmail.com" target="_blank">nguyenhuukhoinw@gmail.com</a>>:<br>
>><br>
>> > Yes. I agree with you but when all controller is down and some users need<br>
>> > to reboot their instances then it won't have ip. This is my worry.<br>
>> ><br>
>> > Nguyen Huu Khoi<br>
>> ><br>
>> ><br>
>> > On Fri, Aug 11, 2023 at 5:00 AM Clark Boylan <<a href="mailto:cboylan@sapwetik.org" target="_blank">cboylan@sapwetik.org</a>><br>
>> wrote:<br>
>> ><br>
>> >> On Thu, Aug 10, 2023, at 12:00 AM, Nguyễn Hữu Khôi wrote:<br>
>> >> > Hello guys.<br>
>> >> ><br>
>> >> > Sometimes I see that my instances won't get IP from Neutron DHCP<br>
>> Agent.<br>
>> >> ><br>
>> >> > Is it good if we set a fixed port for instance and set a static ip in<br>
>> >> > the instance's netplan configuration also?<br>
>> >><br>
>> >> We do this for IPv6 addresses on some of our servers as we've had<br>
>> problems<br>
>> >> with RAs. It seems to work fine in that case. Ideally, this shouldn't be<br>
>> >> necessary for any cloud instance though and it might be worth digging<br>
>> into<br>
>> >> why dhcp isn't working so that it can be corrected.<br>
>> >><br>
>> >> ><br>
>> >> ><br>
>> >> > Nguyen Huu Khoi<br>
>> >><br>
>><br>
>><br>
>><br>
>><br>
>><br>
<br>
<br>
<br>
</blockquote></div>