SIOS SANless clusters

SIOS SANless clusters High-availability Machine Learning monitoring

First 30 days: Key things to know for a newbie to SIOS LifeKeeper or SIOS DataKeeper

by Leave a Comment

First 30 days Key things to know for a newbie to SIOS LifeKeeper or SIOS DataKeeper

First 30 days: Key things to know for a newbie to SIOS LifeKeeper or SIOS DataKeeper

As a relatively new employee, my boss asked me to write down my impressions of SIOS products and things that newbie’s to SIOS might like to know. Here are my thoughts.

Key Product Concepts: Clustering and Data Mirroring

LifeKeeper (Windows or Linux) is clustering software that monitors the whole application stack (network, storage, O/S, database, application software and server hardware). It allows you to specify backup physical or virtual resources (called nodes), and a communication path to connect them. Associations on each node can be created to represent resource hierarchy, for example an association can be made between a database application and the database data. This association keeps the app and the data together when systems are migrated. Lifekeeper also offers the ability to view system logs of the nodes.

DataKeeper is a software tool that is bundled with LifeKeeper. It provides capability to real-time mirror local source drives to destination drives which reside elsewhere on the customer’s network or in the cloud. This provides resilience to a drive outage or failure. Drive data mirroring is handled by SIOS software which does automatic synchronization of data from the source to the destination when changes occur on the source drive. A bitmap is utilized to map the writes to specific blocks and block-level writing is used to perform the copies.

Key Datakeeper and Lifekeeper Product Features and Details

Linux and Windows operating systems are supported for both products.

Lifekeeper offers high IT resilience to problems, keeping systems up and running. If a problem is detected, the system will attempt to restart the application. If this is unsuccessful, it will perform a failover to the standby node. If a communication path goes down, intervention occurs and makes a determination on which node becomes the source node based on data available to each node and provisioned quorum settings.

DataKeeper allows you to configure source and destination connections for Synchronous or Asynchronous drive writing. Synchronous file writing, means that the system completes the write to the destination before it reports that the write is complete; it is slower response, but safer. With asynchronous file writing, the write operations are performed in the background providing faster response. Datakeeper uses WAN throttling and data compression for efficiency.

The combination of products can be used to migrate applications to new VMs or perform maintenance on secondary systems while keeping the primaries live.

Datakeeper and Lifekeeper Product Value

A main benefit of using SIOS Datakeeper is that you can use locally attached drives that already exist on your system. There is no need to plan for and purchase storage hardware. There isn’t the concern of having a RAID controller failing, preventing access to all of the storage, or the whole storage unit being targeted to attacks such as ransomware.

Lifekeeper is available as a Cluster solution using multiple nodes with resource failure detection and failover capability, or is available in a single node variant (Single Server Protection) providing resource failure detection and reboot capability for a single server system. Both are available for Linux and Windows offering protection for a variety of types of customer’s system. LifeKeeper does not require any customized, fault-tolerant hardware.

Linux Lifekeeper supports RHEL9-7, SLES15-12, Oracle Linux 9-6, CentOS 8-6 Rocky 8-6, Miracle 9-8, and can be hosted using VMware vSphere, VMware Cloud on AWS, KVM, Oracle VM Server and Nutanix Acropolis Hypervisor. Linux LifeKeeper installation setup script utilizes package manager tools to install the product.

Key Points to Know

A newbie to SIOS LifeKeeper or DataKeeper can run into a few common points of confusion.  Here are some to be aware of:

Datakeeper:

  • Setting up a mirror – the destination drive has to be at least as large as the source.
  • If the mirror is paused, and changes are made to target, when the mirror is restarted, those changes will be examined and overwritten with the original data from the source.

Lifekeeper:

  • You must bring up your associated child resources before bringing up the parent resource.

SIOS Technical Documentation

Read the official SIOS technical documentation to learn more about the product details and how to troubleshoot issues. From the support page, you can go to the Support Portal.

The Support Portal has the following tabs:

– Solutions tab takes you to a page showing Problem / Solution combinations.

– Cases tab takes you to a page showing various cases in detail

Both pages have search panels allowing the customer to hone in on relevant records.

Key Disaster Recovery Terms and Terminology

Automatic failover – detection of failure and switching of primary and standby drives is handled by the SIOS software, allowing the customer’s system to still function properly should an outage occur.

Application Recovery Kits (ARKs) – are available to protect your business-critical applications and data from downtime and disasters. ARKs provide the capability for performing setup, automation of manual tasks and failover.

Cluster – group of physical or virtual machines that behave as a single system, providing redundancy to create a high-availability resource.

Mirroring – intentionally synchronizing primary drive content changes to a standby drive in real-time.

Switchover – User initiated switching of source and standby drives. Used when system maintenance needs to be performed on a drive.

Lessons and Tips for the Next Newbie:

What has proved most useful for me for retaining what I have learned so far is to take lots of notes, and record screen video on training sessions with peers. This gives you something concrete to refer to at a later date.

Practice setting up mirrors, getting them connected and working, and then performing switch-overs has been very helpful to my understanding of the product. Practice practice practice. The official documentation is an excellent resource to read up on how to perform an operation.

SIOS High Availability and Disaster Recovery

SIOS Technology Corporation provides high availability and Disaster Recovery products that protect & optimize IT infrastructures with cluster management for your most important applications. Contact us today for more information about our services and professional support.

Reproduced with permission from SIOS

How to Avoid IO Bottlenecks: DataKeeper Intent Log Placement Guidance for Windows Cloud Deployments

by Leave a Comment

DataKeeper Intent Log Placement Guidance for Windows Cloud Deployments

How to Avoid IO Bottlenecks: DataKeeper Intent Log Placement Guidance for Windows Cloud Deployments

To ensure optimal application performance, when deploying SIOS DataKeeper it is important to place the intent log (bitmap file) on the lowest latency disk available, avoiding an IO bottleneck. In AWS, GCP and Azure, the lowest latency disk available is an ephemeral drive. However, in Azure, the difference between using an ephemeral drive vs Premium SSD is minimal, so it is not necessary to use the ephemeral drive when running DataKeeper in Azure. In AWS and GCP however, it is imperative to relocate the intent log to the ephemeral drive, otherwise write throughput will be significantly impacted.

When leveraging an ephemeral disk for the bitmap file there is a tradeoff. The nature of an ephemeral drive is that the data stored on it is not guaranteed to be persistent. In fact, if the cloud instance is stopped from the console, the ephemeral drive attached to the instance is discarded and a new drive is attached to the instance. In this process the bitmap file is discarded and a new, empty bitmap file is put in its place.

There are certain scenarios where if the bitmap file is lost, a complete resync will occur. For instance, if the primary server of a SANless cluster is shutdown from the console a failover will occur, but when the server comes back online a complete resync will occur from the new source of the mirror to the old source. This happens automatically, so the user does not have to take any action and the active node stays online during this resync period.

There are other scenarios where bitmap file placement can also impact performance. For instance, if you are replicating NVMe drives you will want to carve out a small partition on the NVMe drive to hold the bitmap file. A general rule of thumb is that the bitmap file should be on the fastest, lowest latency disk available on the instance. It should also be located on a disk that is not overly taxed with other IO operations.

Information on how to relocate the intent log can be found in the DataKeeper documentation. Additional information regarding how the intent log is used can be found in the DataKeeper documentation.

Reproduced with permission from SIOS

How To Resize a SIOS DataKeeper Volume or Mirror

by Leave a Comment

How To Resize a SIOS DataKeeper Volume or Mirror

How To Resize a SIOS DataKeeper Volume or Mirror

In this 4.5 minute video, SIOS demonstrates how to properly resize an existing SIOS DataKeeper volume or mirror. In this case, we are protecting a SQL Server resource via failover clustering. The SIOS DataKeeper resource that we will resize will be Volume ‘s’.

  • Launch SIOS DataKeeper, go to the mirror you are resizing. The reason you do this is for business requirements or because you are running out of space exponentially. First, stop mirroring by choosing Pause and unlock mirror or you can go to the Actions panel on the right and choose Pause and unlock all mirrors if your job has multiple mirrors.
  • It says OK. Once the mirror is paused, now go to the source and you want to grow your space, choose Extend, next, and then finish. Switch over to target and do the same. Extend, next, finish. Go back to the mirror and Choose Continue and lock mirror. The mirror is back in a mirroring state and none of the roles were taken offline.

Let us know if this has been helpful!

How to Remove SIOS DataKeeper Storage from SIOS LifeKeeper

by Leave a Comment

How to Remove SIOS DataKeeper Storage from SIOS LifeKeeper

How to Remove SIOS DataKeeper Storage from SIOS LifeKeeper

Greg Tucker, SIOS Senior Product (Windows) Support Engineer will demonstrate in this 3-minute video, how to properly remove SIOS DataKeeper storage from SIOS LifeKeeper.

It is highly recommended that you remove the DataKeeper resource from the cluster prior to removing DataKeeper.

At the end of the video, Greg shares the SIOS Support contact info in the event there are other questions or issues.

How To Create A DataKeeper Replicated Volume That Has Multiple Targets Via CLI

by Leave a Comment

How To Create A DataKeeper Replicated Volume That Has Multiple Targets Via CLI

How To Create A DataKeeper Replicated Volume That Has Multiple Targets Via CLI

I often help people automate the configuration of their infrastructure so they can build 3-node clusters that span Availability Zones and Regions. The CLI for creating a DataKeeper Job and associated mirrors that contain more than one target can be a little confusing, so I’m documenting it here in case you find yourself looking for this information. The DataKeeper documentation describes this as a Mirror with Multiple Targets.

The environment in this example looks like this:

PRIMARY (10.0.2.100) – in AZ1
SECONDARY (10.0.3.100) – in AZ2
DR (10.0.1.10) – in a different Region

I want to create a synchronous mirror from PRIMARY to SECONDARY and an asynchronous mirror from PRIMARY to DR. I also have to make sure the DataKeeper Job knows how to create a mirror from SECONDARY to DR in case the SECONDARY or DR server ever become the source of the mirror. EMCMD will be used to create this multiple target mirror.

We need to first create the Job that contains all this possible endpoints and define whether the mirror will be Sync (S) or Async (A) between those endpoints.

emcmd . createjob ddrive sqldata primary.datakeeper.
local D 10.0.2.100 secondary.datakeeper.
local D 10.0.3.100 S primary.datakeeper.local D 10.0.2.100 dr.
datakeeper.local D 10.0.1.10 
A secondary.datakeeper.local D 10.0.3.100 dr.datakeeper.
local D 10.0.1.10 A

That single “createjob” command creates the Job. It might be a little easier to look at that command like this:

emcmd . createjob ddrive sqldata 
primary.datakeeper.local D 10.0.2.100 secondary.datakeeper.local 
D 10.0.3.100 S primary.datakeeper.local D 10.0.2.100 dr.datakeeper.
local D 10.0.1.10 A secondary.datakeeper.local D 10.0.3.100 
dr.datakeeper.local D 10.0.1.10 A

Next we need to create the mirrors.

emcmd 10.0.2.100 createmirror D 10.0.1.10 A
emcmd 10.0.2.100 createmirror D 10.0.3.100 S

Our DataKeeper Job should now look like this in the DataKeeper UI

One-to-many DataKeeper Replicated Volume

One-to-many DataKeeper Replicated VolumeAnd then finally we can register the DataKeeper Volume Resource in the cluster Available Storage with this command.

emcmd . registerclustervolume D

DataKeeper Volume in Available Storage

The DataKeeper Volume Resource will now appear in Available Storage as shown below.

DataKeeper Volume in Available StorageYou are now ready to install SQL Server, SAP, File Server or any other clustered resource you normally protect with Windows Server Failover Clustering.

Reproduced with permission from Clusteringformeremortals