5 ms·

Floating IPs: Architect Your Applications for High Availability

64 points by jeffasinger 11y ago

jeffasinger 11y ago
This is a pretty big first step towards easily deploying highly available services on DO. Unfortunately it sounds like you won't be able to fail over to another datacenter, which is unfortunate, but understandable.
viraptor 11y ago
"In order to automate the Floating IP reassignment, we must use the DigitalOcean API. This means that you need to generate a Personal Access Token (PAT)[...] Your PAT will be used in a script that will be added to both servers in your cluster, so be sure to keep it somewhere safe—as it allows full access to your DigitalOcean account—for reference." Need to reassign IP? Store key for the whole account everywhere! Sigh...
geerlingguy 11y ago
This is huge! I don't have to play the 'delete a droplet and recreate another quickly to preserve the IP address' roulette anymore. This will allow me more control during infrastructure deployments on DigitalOcean without futzing with DNS.
praseodym 11y ago
Google Compute Engine has had a similar thing for a while: static external IP addresses can be used anywhere within their region [1] (regions are large, e.g. 'Western Europe' is one region [2]). Of course they also provide global IP addresses with forwarding rules [3]. [1] https://cloud.google.com/compute/docs/instances-and-network#reservedaddress https://cloud.google.com/compute/docs/instances-and-network#... [2] https://cloud.google.com/compute/docs/zones https://cloud.google.com/compute/docs/zones [3] https://cloud.google.com/compute/docs/load-balancing/http/global-forwarding-rules https://cloud.google.com/compute/docs/load-balancing/http/gl...
IgorPartola 11y ago
What? The? Fuck? What year is this? Why is this shit IPv4 only? Seriously, this is not an old feature they are working on, this is brand new stuff. Come one! On top of that, unless you created your instance today you get a dialog that tells you to add a second IPv4 address to eth0, which does not actually work on Linux. I would really love to use features like this, but, ya know, maybe test this stuff first?
- 2bluesc 11y ago
  I'm with you. It'd be nice if they handed out a proper IPv6 prefix to their droplets too. The 16 addresses or whatever it is doesn't count. Bonus points for optionally handing out a /48 as recommended so that docker containers can be allocated /64's. We can dream.
  - IgorPartola 11y ago
    You know what? I just realized that Vultr.com has /64's everywhere. Time to switch. [edit: I am not affiliated in any way with Vultr, was not even a customer until about 30 seconds ago].
    - 2bluesc 11y ago
      Shoot, should have included my referral code. In case anyone else is interested: http://www.vultr.com/?ref=6818844 http://www.vultr.com/?ref=6818844 Vultr also has larger HDD droplets for storage/back-up/archive whatever people want it for (my case bitcoin nodes). DO has been "working on this" for quite some time and it's the most requested feature: https://digitalocean.uservoice.com/forums/136585-digitalocean/filters/top https://digitalocean.uservoice.com/forums/136585-digitalocea...
  - stock_toaster 11y ago
    > Bonus points for optionally handing out a /48 as > recommended so that docker containers can be allocated /64's. A believe that currently a /48 is recommended for "larger" end networks (65K subnets), not for end systems or "home networks"[1] where a /56 is recommended. Would docker instances each need unique subnets? I think a /56 would be sufficient (256 subnets, 4.7×10^21 addresses), maybe even "just" a /64, if docker instances could share the same subnet. [1]: https://tools.ietf.org/html/rfc6177 https://tools.ietf.org/html/rfc6177
ddebernardy 11y ago
How is this different from a virtual IP? https://en.wikipedia.org/wiki/Virtual_IP_address https://en.wikipedia.org/wiki/Virtual_IP_address
icedchai 11y ago
Pretty advanced stuff. I remember doing this 15+ years ago using some Solaris HA software (Veritas, I think.)
- iheartmemcache 11y ago
  VAX VMS could do it ~30 years ago. IBM's AIX has had high-availability since maybe version 5 so 15-20 years on that. Not only that but every component (DB2, WebSphere) was HA ready out of the box (granted ND licenses were like 100k a server). z/OS could do it as soon as it got TCP (40? 50? years). It's the same wheel being crafted every 10 years, just with a little spackle on top. The only thing that feels new to me is the gradual application (pun not intended) of math as it migrates into CS.
sciurus 11y ago
Nice that they're starting to catch up with AWS... from 2008. https://aws.amazon.com/about-aws/whats-new/2008/03/26/announcing-elastic-ip-addresses-and-availability-zones-for-amazon-ec2/ https://aws.amazon.com/about-aws/whats-new/2008/03/26/announ...
- IgorPartola 11y ago
  That's a lot like saying GameStop is catching up to Walmart. They are different products aimed at different markets. I run stuff on both right now and they both have their strengths. For example AWS just rolled out hosted ElasticSearch. Since it's a new product to me, I don't want to jump into maintaining a cluster of ES nodes in production right away. I might experiment with that on DO, but for an actual product I want to release soon AWS's option is better, even though it's about 10x more expensive.

64 points by jeffasinger 11y ago

This is a pretty big first step towards easily deploying highly available services on DO. Unfortunately it sounds like you won't be able to fail over to another datacenter, which is unfortunate, but understandable.

viraptor 11y ago

"In order to automate the Floating IP reassignment, we must use the DigitalOcean API. This means that you need to generate a Personal Access Token (PAT)[...] Your PAT will be used in a script that will be added to both servers in your cluster, so be sure to keep it somewhere safe—as it allows full access to your DigitalOcean account—for reference." Need to reassign IP? Store key for the whole account everywhere! Sigh...

geerlingguy 11y ago

This is huge! I don't have to play the 'delete a droplet and recreate another quickly to preserve the IP address' roulette anymore. This will allow me more control during infrastructure deployments on DigitalOcean without futzing with DNS.

praseodym 11y ago

Google Compute Engine has had a similar thing for a while: static external IP addresses can be used anywhere within their region [1] (regions are large, e.g. 'Western Europe' is one region [2]). Of course they also provide global IP addresses with forwarding rules [3]. [1] https://cloud.google.com/compute/docs/instances-and-network#reservedaddress https://cloud.google.com/compute/docs/instances-and-network#... [2] https://cloud.google.com/compute/docs/zones https://cloud.google.com/compute/docs/zones [3] https://cloud.google.com/compute/docs/load-balancing/http/global-forwarding-rules https://cloud.google.com/compute/docs/load-balancing/http/gl...

IgorPartola 11y ago

What? The? Fuck? What year is this? Why is this shit IPv4 only? Seriously, this is not an old feature they are working on, this is brand new stuff. Come one! On top of that, unless you created your instance today you get a dialog that tells you to add a second IPv4 address to eth0, which does not actually work on Linux. I would really love to use features like this, but, ya know, maybe test this stuff first?

2bluesc 11y ago
I'm with you. It'd be nice if they handed out a proper IPv6 prefix to their droplets too. The 16 addresses or whatever it is doesn't count. Bonus points for optionally handing out a /48 as recommended so that docker containers can be allocated /64's. We can dream.
- IgorPartola 11y ago
  You know what? I just realized that Vultr.com has /64's everywhere. Time to switch. [edit: I am not affiliated in any way with Vultr, was not even a customer until about 30 seconds ago].
  - 2bluesc 11y ago
    Shoot, should have included my referral code. In case anyone else is interested: http://www.vultr.com/?ref=6818844 http://www.vultr.com/?ref=6818844 Vultr also has larger HDD droplets for storage/back-up/archive whatever people want it for (my case bitcoin nodes). DO has been "working on this" for quite some time and it's the most requested feature: https://digitalocean.uservoice.com/forums/136585-digitalocean/filters/top https://digitalocean.uservoice.com/forums/136585-digitalocea...
- stock_toaster 11y ago
  > Bonus points for optionally handing out a /48 as > recommended so that docker containers can be allocated /64's. A believe that currently a /48 is recommended for "larger" end networks (65K subnets), not for end systems or "home networks"[1] where a /56 is recommended. Would docker instances each need unique subnets? I think a /56 would be sufficient (256 subnets, 4.7×10^21 addresses), maybe even "just" a /64, if docker instances could share the same subnet. [1]: https://tools.ietf.org/html/rfc6177 https://tools.ietf.org/html/rfc6177

ddebernardy 11y ago

How is this different from a virtual IP? https://en.wikipedia.org/wiki/Virtual_IP_address https://en.wikipedia.org/wiki/Virtual_IP_address

icedchai 11y ago

Pretty advanced stuff. I remember doing this 15+ years ago using some Solaris HA software (Veritas, I think.)

iheartmemcache 11y ago
VAX VMS could do it ~30 years ago. IBM's AIX has had high-availability since maybe version 5 so 15-20 years on that. Not only that but every component (DB2, WebSphere) was HA ready out of the box (granted ND licenses were like 100k a server). z/OS could do it as soon as it got TCP (40? 50? years). It's the same wheel being crafted every 10 years, just with a little spackle on top. The only thing that feels new to me is the gradual application (pun not intended) of math as it migrates into CS.

sciurus 11y ago

Nice that they're starting to catch up with AWS... from 2008. https://aws.amazon.com/about-aws/whats-new/2008/03/26/announcing-elastic-ip-addresses-and-availability-zones-for-amazon-ec2/ https://aws.amazon.com/about-aws/whats-new/2008/03/26/announ...

IgorPartola 11y ago
That's a lot like saying GameStop is catching up to Walmart. They are different products aimed at different markets. I run stuff on both right now and they both have their strengths. For example AWS just rolled out hosted ElasticSearch. Since it's a new product to me, I don't want to jump into maintaining a cluster of ES nodes in production right away. I might experiment with that on DO, but for an actual product I want to release soon AWS's option is better, even though it's about 10x more expensive.