RSF-1 provides Enterprise-Grade High Availability for ZFS storage servers and includes simple configuration and administration interfaces. The following chapters provide comprehensive details about the installation and use of RSF-1.
- Requirements - Hardware and software requirements for creating a ZFS cluster with RSF-1
- Installation - How to install the RSF-1 software package either from the online repositories or using an offline package
- Licensing - Use of RSF-1 requires the installation of a licence. Find out how RSF-1 licensing works and how to obtain them:
Quick Start Guide
The following chapters provide in-depth information about the configuration and use of an RSF-1 cluster. For a brief overview of using RSF-1 to provide High Availability for a ZFS pool, see the QuickStart Guide.
- Configuration requirements before creating a cluster
- Creating a cluster from the browser
- Creating a cluster using the command line
A service is an entity that the RSF-1 cluster can move between nodes. Although any individual service can run on only 1 cluster node at a time, if there are multiple services configured they can start, stop and move independently, allowing for an Active/Active cluster configuration.
In the case of a ZFS cluster, each service adopts the name of the pool that it controls.
The following sections describe the process of creating a new service to put a ZFS pool under cluster control.
- Prerequesites for creating a ZFS service
- What is a "clusterable pool"?
- What is a VIP and does every service need one?
- Creating a ZFS service from the browser
- Creating a ZFS service using the command line
- What happens when a service is added to the cluster?
Additional ZFS Pools
By default, each service will adopt the name of a ZFS pool and will take control of that pool. However it is possible to add additional pools to a service. If there are multiple pools controlled by one service, those pools will failover together and always be imported on the same node as each other. The following sections give more details about additional pools in a ZFS service:
- Why add additional pools?
- Adding additional pools from the browser
- Adding additional pools using the command line
- What happens when an additional pool is added?
Heartbeats are a fundamental part of any RSF-1 cluster. They provide the communication channel that allows each cluster node to monitor the status of each other node in the cluster. The following sections describe the different types of heartbeat available and how to configure the heartbeats in a cluster.
- What is a heartbeat and what types of heartbeat are available?
- Configuring network heartbeats from the browser
- Configuring network heartbeats using the command line
- Configuring disk heartbeats from the browser
- Configuring disk heartbeats using the command line
Controling a Service
Each service in the cluster has its own state and can be controlled independently. See the following sections for more information on controlling a service:
When RSF-1 detects the failure of a service, it will attempt to failover that service to another node in the cluster. The following sections provide details about service failovers:
- Moving a service manually
- What causes a service to failover?
- What happens when a service fails over?
- How to temporarily prevent a failover
The following sections provide information about creating shares from a clustered ZFS pool
- Creating file shares
- Creating block shares (Logical Units)
There are a number of properties that are available for tuning an RSF-1 cluster. During the initial package installation, these properties are set to sensible default settings and the recommendation is always to avoid changing away from those defaults. However, if necessary, those settings can be changed easily. See the page below for details about the available cluster properties:
- Cluster properties