4 ms·
So there are 2 different things being addressed. There's a HA solution (handle failovers) and then there's operational performance. Introducing cron to manage
by datums 14y ago
So there are 2 different things being addressed. There's a HA solution (handle failovers) and then there's operational performance. Introducing cron to manage this solution, means cron needs to be running and monitored at all times. Also worse case scenario if cron dies and you have a now down nameserver configured.
Agreed on aws I would use their resolver to request the internal ip. Another option is setting up your environment in VPC. With VPC you'll be able to assign a static internal ip to your instance.
btw I did find many reports on the 172.16.0.23 lookup issues.
- kvz 14y agoWe notice the outages because customers tell us to upload x to y.com. If that fails because of 'unable to resolve y.com', we get a support ticket. I guess for your average web 2.0 the effects are less harsh. Also as Amazon said, these outages can be local due to bad iron. It could have been we've been unlucky with that. At any rate, I was pressed to do something about it. Good suggestions otherwise. I'm not sure what will happen with an RDS Multi-AZ failover if you address it by it's static VPC IP? Also about your worst case scenario. It's true that I rely on cron to be working. While other proposed solutions rely on more obscure daemons to be up & running, there still is a risk, and it could be mitigated by just writing all the nameservers to the resolv.conf. I've created an issue for that: https://github.com/kvz/nsfailover/issues/1 https://github.com/kvz/nsfailover/issues/1