Deploy Xpand Topology

Minimum System Requirements

• Minimum of 3 servers required for a Xpand cluster

• Operating System: RHEL or CentOS 7.4+

• Between 8 and 32 CPU cores per server

• SSDs for database storage

• 64GB of RAM

Node Count

• 1 or more MaxScale nodes are required.

• 3 or more Xpand nodes are required.

To avoid problems establishing quorum during a network partition, it is recommended to deploy an odd number of Xpand nodes. If you deploy nodes in multiple zones, it is recommended to use an odd number of zones.

Production Xpand license keys define the maximum number of Xpand nodes which can be deployed. Up to 128 nodes are supported per Xpand cluster.

Node Sizing

Production Xpand license keys define the maximum number of CPU cores which can be deployed.

CPU Recommendations

• 8-32 physical CPU cores per node

• 16 or 20 physical cores recommended

• Hyper-threading enabled

Memory Recommendations

• 64GB or more

AWS EC2 Instance Types

MariaDB Xpand 6.0 supports many different instance types in AWS EC2.

All instances in a Xpand cluster must be the same type.

For MariaDB Xpand 6.0, the following EC2 instance types are recommended:

• Nitro systems, including but not limited to c5x, m5x, r5x, and i4i, with SSDs

• 5th generation instances without a g or a after the 5

• 6i instances

For MariaDB Xpand 6.0, the following EC2 instance types are not recommended, so the xpdnode_install.py script throws a warning during installation:

• c4

• c5

• c5a

• c5n

• i2

• m5

• r5

• r5a

• r5b

For MariaDB Xpand 6.0, the following EC2 instance types are rejected, so the xpdnode_install.py script exits with an error during installation:

• a1

• mac

• t2

• t3

• t3a

• t4g

• Graviton-based instances

GCP GCE Machine Types

• Recommended:

  • n1-highmem-16

  • n1-standard-16

• Not Recommended:

  • n1-highcpu-16 as it has the same CPU power as the highmem and standard, yet less RAM

Operating System

In alignment to the enterprise lifecycle, the Xpand Topology with MariaDB Xpand 6.0 and MariaDB MaxScale 6 is provided for:

• CentOS 7 (x86_64)

• Red Hat Enterprise Linux 7 (x86_64)

File System Requirements

Xpand requires the /data/clustrix directory to reside on the ext4 file system or, for Xpand 23.09 and higher, the XFS file system.

For additional information, see "Example File System Configuration for MariaDB Xpand".

Storage Recommendations

Each Xpand node should have 20+ GiB of SSD storage. Mechanical disks and network-attached storage lack sufficient performance to be used for Xpand data (i.e., /data mount point) and are not supported.

Xpand requires database files to be stored on a local SSD-based file system on a separate volume from the root volume containing the OS. This volume should be configured with RAID-0 for best performance and include all of the SSDs to be used for Xpand. For redundancy, Xpand already writes by default two copies of the data so in the event of a node failure or disk failure, the data is still available and don't require higher RAID volume types as that may impact performance. Xpand recommends using the default mount point of /data to simplify installation.

Solid state drives (SSDs) are available in various levels of quality. Xpand recommends using SSDs that have the following characteristics:

• Enterprise-class SSDs (not consumer-class available from Amazon.com)

• Contains a "Power Loss Protection" feature

• Recommend using SSDs manufactured by Intel (every Intel SSD we've seen has Power Loss Protection)

Less performant disks may be used for logs.

The following storage types are recommended:

• SATA or NVMe SSDs (for DB data) configured in RAID-0

• SATA HDD (for OS, logs, etc)

See the following table for some recommendations:

AWS EC2 Storage Recommendations

• For best performance, MariaDB recommends Ephemeral SSD storage for database data files

• EBS volumes are also supported

GCP GCE Storage Recommendations

• SSD Persistent Disk

• Size of at least 1 TB per disk to achieve the maximum of 10,000 IOPS per disk

• Multiple 1 TB disks may be used for larger storage requirements per VM

Firewall Considerations

Xpand requires a number of ports to be accessible by external applications and for inter-node communication.

One option is to place all Xpand nodes within a secure environment and allow access between all Xpand nodes on all ports.

Another option is to open up the required ports between Xpand nodes.

For additional information, see "TCP Ports for MariaDB Xpand".

DNS Considerations

Xpand requires Xpand node hostnames to be resolvable. Common ways to resolve hostnames are DNS (Domain Name Service) or configuration in /etc/hosts.

Before proceeding with the deployment procedure, ensure that the hostname for each Xpand node is resolvable on all Xpand nodes.

Networking Recommendations

• Separate front and back end networks

• Back end network should be at least 10 Gbps

• 10-Gigabit Ethernet switch with enough ports to connect each Xpand server (or 2x switches for redundancy)

AWS EC2 Networking Recommendations

• Enhanced Networking must be enabled

• Xpand instances must be in a Virtual Private Cloud (VPC)

• Xpand instances within an Availability Zone should be in the same Placement Group for best performance

• All Xpand instances must be in a Security Group that allows all TCP/UDP traffic within the Security Group (i.e., between Xpand instances)

• Xpand clusters deployed across multiple Availability Zones must be within the same region and have <2ms network latency between all nodes

For additional information, see "AWS Security Groups for MariaDB Xpand".

GCP GCE Networking Recommendations

• The VPC Network: Firewall rules must be configured to allow all TCP/UDP traffic between all Xpand VMs

• Xpand clusters deployed across multiple Zones must be within the same region and have <2ms network latency between all nodes

System User Accounts

By default, Xpand and MaxScale use the following OS user accounts. These accounts are created during the installation process:

For additional information, see "Operating System User Accounts for MariaDB Xpand".

AWS EC2 Load Balancer

• Xpand leverages a load balancer to present a single IP to the application servers, and spread DB connections equally across all Xpand instances

• Using AWS's Elastic Load Balancer (ELB) is recommended due to its ease of operation

  • The Network Load Balancer offers the best performance, but requires considerations regarding how the Security Groups are configured

  • The Classic Load Balancer is easier to configure with Security Groups, but tends to add latency to traffic passing through it

• Alternatively, a software load balancer (e.g., HAProxy) running on a separate EC2 instance, or directly on the application server is also suitable

• The ELB should be created as an Internal Load Balancer:

  • http://docs.aws.amazon.com/ElasticLoadBalancing/latest/DeveloperGuide/elb-internal-load-balancers.html

GCP GCE Load Balancing

• Xpand leverages a load balancer to present a single IP to the application servers, and spread DB connections equally across all Xpand instances

• Google Load Balancer:

  • Select: TCP Load Balancing

  • Select: Internal facing

  • Select: Multiple Regions (or not sure yet)

• Alternatively, a software load balancer (e.g., HAProxy) running on a separate GCE VM instance, or directly on the application server is also suitable

MaxScale Configuration Management

MaxScale can be configured using several methods. These methods use the MaxScale REST API.

This deployment procedure uses MaxCtrl. Alternatively, MaxGUI or direct REST API access could be used.

MaxScale Service Management

The systemctl command is used to start and stop the MaxScale service.

Xpand Service Management

The clx command is used to start and stop the Xpand service.

This command is usually executed as the xpandm system user account. For additional information, see "MariaDB Xpand System User Accounts".