Category Archives: Database

Everything you wanted to know about Netezza networking but were afraid to ask (Part Two)

Database, Netezza, Networking, , , ,

This blog post is the second in a three-part series with the goal of answering questions you might have about Netezza networking. The first part concentrates on basic Netezza networking, whereas this second part covers more advanced networking concepts. For advanced configuration options, you can check out the upcoming third part of this blog post.

Network bonding

You have two hosts: active and passive. Each has its own IP address. These IP addresses are not floating. These are called host IPs. Since you want to have maximum redundancy on all components, there are actually two physical network devices virtually bound together to create virtual networking devices (one for each host). Both hosts have two physical network devices that carry one IP address. This is called network bonding.

Let’s say both of the hosts have network devices eth6 and eth7 and they create a coupled virtual device called bond2. We usually use bond0 and bond1 internally, so the first bonded device for external use is normally bond2.

For the virtual device bond2, you can assign an IP address and connect to a host. Both active and passive hosts will have this device and both of the hosts will have their own individual IP address, which is bound to this virtual device.

Virtual IP

If you think of this from an applications point of view, it wouldn’t make sense to connect to the host IP, since if the active host fails, you would need to re-configure applications to use the new active host, which has a different IP.

That’s why applications use virtual IP. Virtual IP is actually an IP alias, which is bound to an active host. Hosts run standard Linux operating systems, so if you are familiar with Linux, it’s easy to explain. If not, it’s still not rocket science. On Linux, you can easily add IP aliases on top of any physical, or virtual for that matter, network device . If you have physical network device eth0 with fictional IP address 192.168.1.100, you can add another IP address to that same physical device just by assigning an IP to device eth0:0. Next you add to device eth0:1 and so on.

In this case, you have virtual network device bond2, which is a bonded device having physical devices eth6 and eth7 behind it. If you lose eth6, you are still good as long as physical device eth7 is good. To connect to either of the hosts directly, you would use the IP address assigned to bond2 on the particular host, or rather the host name you have assigned in your domain name server (DNS) for that IP address.

Floating IP

As I said, applications connect to a virtual IP. The virtual IP is assigned to virtual network device bond2:0. It only exists on an active host. This is something called a floating IP, and it is always on the active host. If Host 1 fails, it will be on Host 2. If, as in my example, device eth6 fails, you have bonded device bond2, which consists of eth6 and eth7, the floating IP is still good on that same appliance as before.

There are two virtualization layers here. One is done though network bonding, the other is done through cluster software. If one of the network devices physically breaks, the network bonding will do the trick, and you are still good to go. If the other appliance breaks, you have clustering software, which can deactivate the bond2:0 on the failing host and create bond2:0 on new active host.

So the bond2:0 always has the virtual IP your applications are able to use. You should, of course, always assign host names in your DNS for this virtual IP, and use this host name in your applications instead of using IP addresses directly. That way, if you ever need to change the IP address for the virtual IP, you don’t need to change configurations for several applications. Instead, you just have to change the IP for the host name you have defined for the virtual IP in your DNS configuration.

What about changes to the default configuration?

I will cover advanced configuration options in part three of this blog post. If you have any network-related questions or suggestions, please add them below in the comments. You can also follow me on Twitter @TVaattanen to discuss more about Netezza.

Everything you wanted to know about Netezza networking but were afraid to ask (Part One)

Database, Netezza, Networking, , ,

This blog post is the first of three parts informing you about everything you always wanted to know Netezza networking but were afraid to ask.

Simplicity

PureData System for Analytics is a simple appliance for serious analytics. There is minimal tuning involved and it can be up and running in hours with minimal administration. Since it is so simple, you might be afraid to ask questions such as the following:

  • How would my applications connect to the appliance?
  • How am I going to manage the appliance?
  • What is the network bandwidth?

The answer to all of the above questions is that you can do it through a standard TCP/IP networking interface. Well, how do you network with PureData System for Analytics, then?

Connectivity

It’s simple because it’s an appliance. It has basically one IP address, or host name, that your applications use to connect. To manage the appliance, you can use the same IP address or host name for sure, but let’s be a bit more exact.

The PureData System for Analytics appliance has five external IP addresses and six ethernet drops by default.

The appliance consists of two hosts and several S-Blades or Snippet Processing Units (SPUs). One of the hosts is active and the other is passive. You always connect to the appliance through the active host. On the application level, you never connect through any other component. To connect to the active host you use something called a virtual IP or the Open Database Connectivity (ODBC) host name. That IP or host name is for applications. It is a floating virtual IP address which is always on an active host.

You should always make sure there is a host name assigned to the virtual IP in your name server so that applications can connect through a Fully Qualified Domain Name (FQDN) instead of an IP address.

Management IPs

To manage the appliance, you can connect directly by using the IP addresses assigned to both hosts, which are called the host IPs. These IPs are assigned to virtual network device bond2 by default, which is created from two physical network devices for redundancy. That would be a normal situation.

You have other options as well. With an integrated management module (IMM) that has an IP address, you can connect and get console access through the network instead of needing to be physically near the appliance.

In summary

There are two physical network devices on both hosts, which creates a virtual network device bond2 by default and one physical network device on IMM on both hosts. That makes six ethernet drops.

There are five IP addresses: One IP address for applications, one IP for both of the two hosts and one IP address for IMM on both of the hosts. Here’s a little more detail:

  • One VIP and ODBC host name: You should define the host name in your name server for VIP. That way, applications are able to use a floating IP through the ODBC host name to connect to the appliance. This IP is assigned to active hosts automatically.
  • Two Host IPs: These are by default assigned to virtual device network bond2 on both hosts. If you want to connect to host 2, you use the IP address assigned to device bond2 on host 2.
  • Two IMM IPs: Both hosts have an integrated management module, you can use them to get direct console access through the network.

The rest of the networking

I will cover more advanced networking topics in part two and three of this blog post series. If you have PureData System for Analytics networking related questions in mind you did not dare to ask earlier, please do it below by commenting on this post. You can also follow me on Twitter @TVaattanen to discuss more about Netezza