m
Our Mission Statement
This is Photoshop's version of Loremer Ipsn gravida nibh vel velit auctoregorie sam alquet.Aenean sollicitudin, lorem quis bibendum auci elit consequat ipsutis sem nibh id elit.
Follow Us
Top
How to Set Up External and Public Interfaces for Cloud Instances in VoltDB - VoltDB
9794
post-template-default,single,single-post,postid-9794,single-format-standard,mkd-core-1.0,highrise-ver-1.0,,mkd-smooth-page-transitions,mkd-ajax,mkd-grid-1300,mkd-blog-installed,mkd-header-standard,mkd-sticky-header-on-scroll-up,mkd-default-mobile-header,mkd-sticky-up-mobile-header,mkd-dropdown-slide-from-bottom,mkd-dark-header,mkd-header-style-on-scroll,mkd-full-width-wide-menu,mkd-header-standard-in-grid-shadow-disable,mkd-search-dropdown,mkd-side-menu-slide-from-right,wpb-js-composer js-comp-ver-5.2.1,vc_responsive
VoltDB / Best Practices  / How to Set Up External and Public Interfaces for Cloud Instances in VoltDB

Blog

How to Set Up External and Public Interfaces for Cloud Instances in VoltDB

Upwards of 50% of VoltDB customers deploy in public and private clouds, so we get queries regularly on how to set up interfaces for cloud instances. One question that’s come up a few times is, ‘How do I configure VoltDB to be secure but still allow me to monitor through the web interface from my office?’

VoltDB allows this by letting you bind particular functions to network interfaces.  In most deployments, most of the client traffic is also from within the cloud.

VoltDB users can set both an external interface and a public interface in their VoltDB network configuration. The difference between these, however, is confusing to some; external usually means public. In VoltDB, the public interface is useful for cloud systems where the address used from outside the cloud is not actually an interface that is visible within the instances. For example, with AWS, you get a public interface that you can’t bind to from the host. That is where you set a public interface.

This is helpful for a VMC which has a selector for switching between hosts in a cluster. Without it, the VMC will not know how to attach to the other servers.

To further illustrate, consider this system.

Setting up Cloud Instances in VoltDB

 

All addresses are internal to the cloud. The internal interfaces and their external counterparts are set to 10.0.1.x addresses and nothing is translated. If you ran ifconfig on the cluster nodes, they would not list 54.154.29.xxx, so you couldn’t bind to this if you wanted to, which is a problem.

Desktops outside the cloud address things through their 54.154.29.xxx address. The NAT handles routing and connects you to the requested node. If publicinterface was not set, this process would work fine. However, there is a slight issue, due to the way VMC gathers information about all the nodes from @Systeminformation OVERVIEW and makes a list of the other nodes.

If the public interface is not set, then a query from the VMC uses the external interface and gives 10.0.1.1:8080, which is not accessible outside the cloud. However, when the public interface is set, then the VMC gives 54.154.29.11:8080, which works.

To summarize:

  1. Do not make your VoltDB internal mesh go through VMC.
  2. If any application needs to find out how to connect to other nodes, set publicinterface.
  3. You can put your applications anywhere you want – inside with no NAT, or outside and going through the NAT. VoltDB doesn’t care about that system design choice.