> Op 12 november 2013 om 13:04 schreef Shanker Balan > <shanker.ba...@shapeblue.com>: > > > Comments inline. > > On 12-Nov-2013, at 5:16 pm, Lennert den Teuling <lenn...@pcextreme.nl> wrote: > > >> Op 12 november 2013 om 2:18 schreef Nick Wales <n...@nickwales.co.uk>: > >> > >> > >> Thanks Lennert. > >> > >> My issue isn't around the state of the VR as such, we've destroyed and > >> brought back plenty with no issue, more so the impact it going down will > >> have on my instances. > >> > >> We're looking at consolidation ratios of 40 to 1 so Pods will have a large > >> number of instances. > >> > >> We have been trying to work out the best way to use external DNS servers my > >> main issue there has been that puppet requires the FQDN of the instance > >> which they won't get until the external DNS servers respond appropriately > >> which slows things down. > >> > >> We have been testing scripts to push DNS entries from the instances at > >> start up which seems to work ok. How do you approach this problem? > > > > If i understand you correctly, what you probably want is to directly update > > your > > (main) nameservers when a VM is started. I heard my colleague talking about > > writing something for CloudStack which automatically add a records for the > > hostname and reverse DNS when VMs are being deployed. This is something we > > are > > currently looking into. > > Cloud-init would be a nice framework to standardise on as it already > supports cloudstack meta-data services. One would have to write a customer > DNS registration module and enable it in their template. > > Puppet etc would be a overkill for this task.
Indeed, for setting thing like the hostname, cloud-init would be just fine no need to use puppet. In our case , the customer has (root)access to the VM, so i'm not sure if creating the correct (r)DNS records is something i would trigger from within the VM. It's an option of course, but i rather not have the client looking into the code we use to manipulate the DNS for example. If i would manage the VMs myself it would be definitely be a option. > > > > If you systems (outside) CloudStack also use this nameservers (which is the > > case > > in our situation) the FQDN should be resolvable at once. Of course it could > > take > > some time for it to be available world-wide. > > > > It seems that there is already some code available which gets triggered at > > these > > events, but you still need to implement you own DNS infrastructure. > > AWS Route 53 would be a good choice. Looks like some already has > added Router 53 support to cloud-init. > > https://github.com/lovelysystems/cloud-init/blob/master/cloudinit/CloudConfig/cc_dns.py Interesting, I'm not that familiar with cloud-init is seems! :-) > > > > Cheers, > > Lennert > > > >> Nick > >> > >> > >> > >> > >> On 11 November 2013 17:44, Lennert den Teuling <lenn...@pcextreme.nl> > >> wrote: > >> > >>>> Op 12 november 2013 om 0:07 schreef Nick Wales <n...@nickwales.co.uk>: > >>>> > >>>> > >>>> I have a couple issues with the current setup involving the virtual > >>> router. > >>>> > >>>> 1. I'm not using the VR for port forwarding / VPN / routing or anything > >>>> traffic related so it would seem to me to be relatively trivial to have a > >>>> secondary virtual router that just provides DNS, userdata & metadata. > >>> This > >>>> would be sufficient for all my failover requirements. > >>>> > >>>> 2. It would also be useful to be able to set DNS options in a basic zone. > >>>> Timeout, attempts etc. Timeout on linux is set to 5 seconds which is an > >>>> eternity in case of failure. > >>>> > >>>> Are people comfortable with a single VR in a basic zone, and what > >>>> mitigations can be put in place to avoid any fallout from failures? > >>> > >>> Hi Nick, > >>> > >>> When the VR is down, you could run into some issues especially when you > >>> are > >>> recovering from hardware failure. In this case the instances that are down > >>> will > >>> not start until you fixed the router. This is quite logical cause they > >>> need DHCP > >>> for example. > >>> > >>> The router startup was quite slow in the past. We run about 400 VMs per > >>> pod, and > >>> you will not be very happy when it takes about 1 hour to reconfigure all > >>> DHCP > >>> entries. Luckily, the VR startup time has been improved a lot lately, and > >>> for us > >>> the same process takes about 15 minutes but still, it could be faster in > >>> the > >>> future. > >>> > >>> So when the VR doesn't boot you cannot boot your other VMs which could be > >>> problematic even if it takes only 15 minutes. Because of this we are > >>> planning to > >>> move SSVMs (including the VR) to a seperate cluster so it doesn't run next > >>> to > >>> instances of our clients so both cannot (or shouldn't) be offline at the > >>> same > >>> time. > >>> > >>> Anyway, if you plan to run like up to 50 instances in a pod (using the > >>> same VR), > >>> this will won't be a problem for you cause VR startup time will probably > >>> be > >>> acceptable. > >>> > >>> When you recreate the VR (which you should be able to do whenever you > >>> want), it > >>> will likely receive a new IP and you VMs need to renew their DHCP lease to > >>> receive the new IP adres for DNS. This is why we have chosen not to use > >>> the DNS > >>> server of the VR. > >>> > >>> Hope this helps! > >>> > >>> Met vriendelijke groet / Kind regards, > >>> > >>> Lennert den Teuling > >>> Tel direct: +31 (0)118 700 210 > >>> > > -- > @shankerbalan > > M: +91 98860 60539 | O: +91 (80) 67935867 > shanker.ba...@shapeblue.com | www.shapeblue.com | Twitter:@shapeblue > ShapeBlue Services India LLP, 22nd floor, Unit 2201A, World Trade Centre, > Bangalore - 560 055 > > CloudStack Bootcamp Training on 27/28 November, Bangalore > http://www.shapeblue.com/cloudstack-training/ > > > > > This email and any attachments to it may be confidential and are intended > solely for the use of the individual to whom it is addressed. Any views or > opinions expressed are solely those of the author and do not necessarily > represent those of Shape Blue Ltd or related companies. If you are not the > intended recipient of this email, you must neither take any action based upon > its contents, nor copy or show it to anyone. Please contact the sender if you > believe you have received this email in error. Shape Blue Ltd is a company > incorporated in England & Wales. ShapeBlue Services India LLP is a company > incorporated in India and is operated under license from Shape Blue Ltd. Shape > Blue Brasil Consultoria Ltda is a company incorporated in Brasil and is > operated under license from Shape Blue Ltd. ShapeBlue is a registered > trademark. Met vriendelijke groet / Kind regards, Lennert den Teuling Tel direct: +31 (0)118 700 210
