Since XDCR involves communication between clusters, it is important you know which protocol is in use so you can configure the XDCR connections. So the Volt Helm chart provides the .ipFamilies property so you can choose which protocol to use for XDCR communication. There are two flavors of the .ipFamilies property, depending on how you are configuring XDCR. If you are establishing an XDCR environment within a single namespace (as described in Section 8.4, “Configuring XDCR in Local Namespaces”), you set the IP version in the cluster.serviceSpec.dr.ipFamilies property, as in the following example that sets the IP family to IPv6:

cluster:
  serviceSpec:
    dr:
      enabled: true
      ipFamilies:
        - IPv6

If you are configuring per pod XDCR, you select the IP version in the cluster.serviceSpec.perpod.dr.ipFamilies property; as in this example:

cluster:
  serviceSpec:
    perpod:
      dr:
        enabled: true
        ipFamilies:
          - IPv6

It is possible to customize the network environment even further using third-party networking services, such as Multus — which is a container networking service (CNI) plugin that gives pods access to multiple networks. Again, how you configure third-party services is beyond the scope of this manual and differs from one service to the next. However, these services provide instructions to the pods through annotations that you include in your Helm chart. Specifically, Volt supports annotation properties that affect the XDCR settings, which Multus can use to specify alternate networks, as in the following example:

cluster:
  serviceSpec:
     dr:
        annotations: 
           aviinfrasetting.ako.vmware.com/name: my-infra-sets
  clusterSpec:
     additionalAnnotations:
       k8s.v1.cni.cncf.io/networks: my-custom-network

See the Multus documentation for more information.

The annotations shown in the preceding section tell a container networking service (CNI) such as Multus which secondary networks to attach to each pod. When a pod has more than one network interface, VoltDB can decide which interfaces to assign to what roles. By default, VoltDB advertises its primary address (eth0) for both clients and remote XDCR clusters. If you want client or replication traffic to use a secondary network instead, assign the specific interface to the corresponding cluster.clusterSpec.network property.

You configure each type of connection separately. The network.client property sets the address that topology-aware client applications connect to, and network.dr sets the address a remote cluster uses to establish cross datacenter replication (XDCR). You can configure either or both, and the two need not use the same interface.

For each connection, the resolveBy property specifies how VoltDB selects the address from the pod's available interfaces when it starts. Setting resolveBy to cidr selects the interface whose address falls within the subnet you specify with the cidr property; setting resolveBy to interface selects the address on the interface you name with the interface property. (Multus typically names secondary interfaces net1, net2, and so on.) For example, the following configuration assigns the client address from a secondary subnet:

cluster:
  clusterSpec:
    network:
      client:
        resolveBy: cidr
        cidr: 192.168.100.0/24

By default the network property changes only the address VoltDB advertises; the database still listens on all interfaces. To also restrict a connection's listener to its resolved interface — so that its traffic cannot travel over the primary network — set the bind property to true on that YAML block. And on a dual-stack pod, where an interface can have both an IPv4 and an IPv6 address, set ipFamily to either ipv4 (the default) or ipv6, to choose which one VoltDB advertises. This per-connection setting is distinct from the cluster.serviceSpec... ipFamilies property described in the previous section, which selects the protocol for the XDCR service rather than the address resolved on the pod.

The following example selects each network by name, binds each listener to its interface, and advertises the IPv6 address:

cluster:
  clusterSpec:
    network:
      client:
        resolveBy: interface
        interface: net1
        bind: true
        ipFamily: ipv6
      dr:
        resolveBy: interface
        interface: net2
        bind: true
        ipFamily: ipv6

Finally, the timeout property specifies how long startup waits for the chosen address to appear. (The timeout is specified in seconds with a default of 120, or 2 minutes.) If VoltDB cannot resolve the address in the allotted time — for example, because of an incorrect subnet or interface name, or a secondary network that is not attached — it stops attempting to resolve the address. The node does not start and the pod stays in the Running state without becoming Ready. You can use the pod's log to see whether and how each address was resolved.