April 3, 2018 | Written by: Jay Kidambi and Allan Hu
Share this post:
Following our new IBM Cloud Load Balancer service that went live last year, we’ve just added additional capabilities to enhance your experience in cloud-native network services.
Our IBM Cloud Load Balancer is an infrastructure layer (IaaS) load balancer that distributes traffic “locally,” and can be configured via an API or a web UI. With high availability (HA) by default, it provides on-demand scalability, as well as usage-based billing for a fresh way to manage high-density traffic in the cloud, along with the ability to pay only for what you use.
This blog will explore new additions to the service, including:
• Horizontal scaling
• Internal-facing load balancer
• Monitoring metrics
• Cipher suite customization
IBM Cloud Load Balancer scales up automatically when load increases (and scales down as load decreases). When the load balancer is created, it starts with two appliances, but the number of appliances can go up (to 16, as of this writing) as our monitoring system detects an increase in the load. The IP addresses of each of the active appliances is added as DNS A-Records to the Fully Qualified Domain Name (FQDN) of the load balancer.
As always, we ask that clients use the FQDN of the load balancer instead of its IP addresses when communicating with it. This ensures good load distribution across all available load balancer appliances, in addition to ensuring that if an appliance is taken off the service for any reason, clients will naturally stop using that instance.
IBM continuously monitors the load balancer appliances, and if we detect a loss of communication with an appliance, we take the appliance out of service (by removing it from DNS), and immediately replace it with another instance to restore full capacity. This new capability requires no special configuration– it is enabled by default, at no additional cost.
Internal load balancer
In its first incarnation, IBM Cloud Load Balancer was of the “Public” variety, which supports clients on the public Internet, while the server/application is on your IBM Cloud private network. By request, a highly-demanded “Internal” version of our IBM Cloud Load Balancer that wouldn’t be exposed publicly, but could be used to load balance applications within their IBM Cloud private networks (in a multi-tiered deployment, for instance, as shown in the figure below). It would be both secure, as well as consistent with the load balancer that they were already using on the public side. As a result of high demand, we quickly delivered the Internal load balancer feature to the IBM Cloud Load Balancer service.
Figure: Using a combination of public and internal load balancers for a 3-tier application (logical representation)
The internal load balancer works the same way, and has all the same features as the public load balancer–including the horizontal scaling that we delved into earlier–except that it’s only exposed within your private network. All you’ll need to do now when creating a new load balancer is select the Internal option. Like the public load balancer, we assign a FQDN to each internal load balancer. These host names are registered publicly, but the addresses are only relevant within the private network where they are deployed. They are not a recommended best practice in any other environment, even if the hostname can be DNS resolved publicly.
You can now leverage the “IBM Cloud Monitoring” service to monitor the following performance metrics associated with your load balancer and application:
• Connection rate
• Active connections
Figures: IBM Cloud monitoring service dashboard views
This new feature requires your IBM Cloud IaaS and PaaS accounts to be linked, with a few simple steps. Up to two weeks of samples are collected and displayed by the load balancer web UI. The data can also be viewed on the IBM Cloud Monitoring service portal. If you require data for longer than two weeks, depending on the volume of other cloud metrics you may be sending to your Cloud Monitoring instance, you may need to upgrade your monitoring plan.
Cipher suite customization
To improve upon the security of the service, you’re now allowed to customize the cipher suites that are used when the load balancer is configured to perform SSL termination.
When you enable SSL termination on our load balancer (by selecting HTTPS as the front-end protocol), we enable a carefully selected default set of cipher suites that conform to best security practices. We keep a close watch on any new vulnerabilities that may be discovered, and update the list accordingly. This, along with seamless security updates of software and hardware components, helps to keep your applications secure at all times.
The following image shows how you can customize the cipher suites that your load balancer service can support.
On the horizon of IBM Cloud Load Balancer
As our roadmap evolves over time, we expect to deliver new services, features, and capabilities as we extend our -as-a-Service portfolio lineup to support your cloud-native workloads. We couldn’t be more excited as we modernize beyond the realms of today’s traditional cloud infrastructure offerings to deliver best-in-class security, reliability, and performance to you, our customers.
For your reference
We invite you to learn more about IBM Cloud Load Balancer, our Cloud IaaS offering, in the following documentation:
• Getting started with IBM Cloud Load Balancer
• IBM Cloud Catalog: IBM Cloud Load Balancer services