SIOS SANless clusters

SIOS SANless clusters High-availability Machine Learning monitoring

Benefits of SIOS Protection Suite/LifeKeeper for Linux

by Leave a Comment

Benefits of SIOS Protection SuiteLifeKeeper for Linux

Benefits of SIOS Protection Suite/LifeKeeper for Linux

  • SIOS software supports multiple operating system versions and flavors (both Linux and Windows).
    • Consistent user experience to protect mission-critical resources regardless of the operating system.
  • SIOS delivers high availability solutions for multiple environments including on-premises, virtualized (VMware) and cloud environments including public platforms from AWS, Azure, Google Cloud as well as privately hosted cloud environments. The same tools can be used across different environments.
    • Hybrid environments are also supported. It is possible to configure an on-premise node as the primary location with the secondary node being hosted in a private cloud and a third node located on a public cloud platform providing an additional DR (disaster recovery) option.
  • SIOS provides application-aware protection mechanisms including Application Recovery Kits (ARKs), available for the world’s leading providers of enterprise applications and databases.
    • Our comprehensive library of ARKs protect the broadest range of applications ‘off-the-shelf’.
    • Other ‘non-standard’ or legacy applications can be protected with the built-in ‘GenApp’ ARK or by developing a custom ARK either in-house or in collaboration with SIOS engineers.
  • Unlike open-source tools (which force the user to manually establish environmental parameters in advance and then type a complex set of command-line parameters), a series of wizard based installation and configuration screens enables intuitive selection of resources requiring protection and helps in selecting the type and extent of protection to be provisioned.
    • Wizards scan the system and environment to identify the resources to protect. In most cases the operator only needs to confirm default selections and enter unique environment-specific host IDs etc. to complete the installation.
    • This reduces the likelihood of misconfiguration of the HA solution and the inevitable unexpected downtime as the result of a system or application failure.
  • SIOS provides a comprehensive range of technical support options including 24×7 critical support, offering support options tailored to the available budget, systems complexity or criticality of the application requiring high availability.

Reproduced with permission from SIOS

How To Activate a License for SIOS Protection Suite for Linux

by Leave a Comment

How To Activate a License for SIOS Protection Suite for Linux

How To Activate a License for SIOS Protection Suite for Linux

Since you have acquired your SIOS Protection Suite for Linux software, you will need to activate your license.  This seven-minute video will help you get started. It walks you through all of the steps needed to begin running your SIOS Protection Suite for Linux software.  Watch as a SIOS support representative demonstrates the steps that are necessary to install SIOS licenses: how to insert entitlement/activation IDs, how to obtain and insert host IDs, and activation file download.

The video illustrates where to access software for download, how to view and validate host name and ID from purchased or trial entitlements, and how to download the activation files contained in your welcome email to complete the process. You will also learn how to access our SIOS Documentation portal, where you can find release notes, installation guides, technical documentation and in depth information on SIOS Protection Suite for Linux as well as a wide range of topics for every SIOS product.

Receive helpful tips and convenient insights on how to complete the steps quickly and easily. See how simple it is to start running SIOS Protection Suite for Linux.

How To Activate a License for SIOS Protection Suite for Linux

Reproduced with permission from SIOS

How to Fix Inherited Application Availability Problems

by Leave a Comment

 

 

How to Fix Inherited Application Availability Problems

What to do when you inherit a mess

I grew up in a large immediate family, and an even larger group of well-meaning aunts, uncles, and family friends.  Anyone who has ever been a part of a large family has probably, on more than one occasion, received a hand-me-down or had well-intentioned relatives give you a freebie. And if so, you know that beneath the surface of that cool-sounding inheritance, the rumored stylish clothes, or the old “family car” a nightmare could be lurking.  Suddenly, your sudden fortune on four wheels feels like a curse that is two-thirds money pit and one third eye-sore.

So what do you do when you inherit a mess of Application Availability Problems?  Well some DIYers bring in the dumpsters and start fresh. But this isn’t HGTV and we aren’t talking about inherited furniture but an inherited application availability problem. You usually know you have a mess on your hands the first time you try to do a cluster switchover for simple, planned maintenance and your application goes offline.  Now, what do you do when you have inherited a high availability mess.

Two Practical Tips For When You Inherit A High Availability Mess (I mean responsibility)

I. Research

Perhaps one of the best things you can do before taking action is to gather as much data as quickly as possible.  Of course, the state of your inheritance might indicate the speed at which you’ll need to gather your data.  Some key things to consider during your research of to solve your Application Availability Problems:

  1. Previous owner. Research the previous owner of the configuration including their chain of command, reach of authority, background, team dynamics and if possible, charter.  Find out what were the original organizational structures.
  2. Research what was done in the past to achieve high or higher availability, and what was left out.  In some environments, the focus for high availability falls squarely on a portion of the infrastructure while neglecting the larger workflow. Dig into any available requirements. As well as what changes have been implemented or added since the requirements were originally instated.  If you’re in the midst of a cloud migration, understand the goals of moving this environment to the cloud.
  3. Owners and requirements provide a lot of history. However, you’ll also want to research why key decision makers made the choices and tradeoffs on designs and solutions, as well as software and hardware architecture requirements.  Evaluate whether these choices were either successful or unsuccessful. Your research should focus on original problems and proposed solutions.
  4. You may also want to consider why the environment you inherited feels like a mess.  For example, is it due to lack of documentation, training, poor or missing design details, the absence of a run book, or other specification details.
  5. Research what, if any, enterprise grade high availability software solutions have been used to complement the architecture of virtual machines, networks, and applications. Is there a current incumbent?  If not, what were the previous methods for availability?

II. Act

Once you’ve gathered this research, your next step is to act: update, improve, implement, or replace.  Don’t make the mistake of crossing your fingers and hoping you never need a cluster failover.

  1. Upgrade

    In some cases, your research will lead to a better understanding of the incumbent solution and a path to upgrade that solution to the latest version.  Honestly, we have been there with our own customers.  Transitions are mishandled. A solution that works flawlessly for years becomes outdated.

  2. Improve

    Consider alternatives if an upgrade is not warranted. If the data points to other areas of improvement such as software or hardware tuning, migration to cloud or hybrid, network tuning, or some other identified risk or single point of failure.  Perhaps your environment is due for a health check or the increases in your workload warrants an improvement in your instance sizes, disk types, or other parameters.

  3. Implement

    In other cases, your research will uncover some startling details regarding the lack of a higher availability strategy or solution. In which case, you will use your research as a catalyst to design and implement a high availability solution. This solution might necessitate private cloud, public cloud, or hybrid cloud architectures coupled with the enterprise grade HA software to enable successful monitoring and recovery.

  4. Replace

    In extreme cases, your research will lead you to a full replacement of the current environment. Sometimes this is required when a customer or partner migrated to the cloud. But their high availability software offering was not cloud ready. While many applications boast of being cloud ready, in some cases this is more slideware than reality.  Your on-premise solution is not cloud ready? Then your only recourse may be to go with a solution that is capable of making the cloud journey with you, such as the SIOS Protection Suite products.

As VP of Customer Experience for SIOS Technology I experienced a situation that shows the importance of these steps – when our Services team was engaged by an enterprise partner to deploy SIOS Protection Suite products.  As we worked jointly with the customer, doing research, we uncovered a wealth of history. The customer professed to have a limited number of downtime or availability issues. But our research revealed an unsustainable and highly complex hierarchy of alerts, manually executed scripts, global teams, and hodgepodge of tools kludged together. We were able to successfully architect and replace their homemade solution with a much more elegant and automated solution with this information. Best part, it was wizard based, including automated monitoring, recovery, and system failover protection. No more kludge. No more trial-and-error DIY. Just simple, reliable application failover and failback for HA/DR protection.

If you have inherited a host of Application Availability Problems, contact the deployment and availability experts at SIOS Technology Corp. Our team can walk you through the research process, help you hone your requirements. Finally, upgrade, improve, replace or implement the solution to provide your enterprise with higher availability.

– Cassius Rhue, Vice President, Customer Experience

Reproduced from SIOS

Quick Start Guide to High Availability for SQL Server Using SIOS Protection Suite for Linux

by Leave a Comment

 

Quick Start Guide to High Availability for SQL Server Using SIOS Protection Suite for Linux

This guide is intended to illustrate Microsoft SQL Server protection using SIOS Protection Suite for Linux. The environment used here is VMware ESXi with virtual machines added running CentOS 7.6. Microsoft SQL 2017 is being used to create a database server. Database and transaction logs will be stored on local disks that will be replicated between nodes using DataKeeper – demonstrating that shared storage could be used as a simple replacement for local disks.

This guide is available here as a pdf.

Download Required Microsoft Software

  1. Open the following Microsoft guide to installing SQL at https://docs.microsoft.com/en-us/sql/linux/sql-server-linux-setup?view=sql-server-ver15

Plan SQL Environment Configuration

The following configuration settings will be used for creating the cluster environment described by this quick-start guide. Adapt your configuration settings according to your specific system environment.

General Configuration

  1. The example we installed during this quick start guide uses CentOS. The Red Hat instructions apply since CentOS is binary compatible with Red Hat.
  2. The example in this quick start guide will be very similar, whether they are running in a VMware environment, cloud or physical installations.

Node 1 configuration

  • Hostname: IMAMSSQL-1
  • Public IP: 192.168.4.21
  • Private IP: 10.1.4.21
  • /dev/sdb (10GiB)
  • /dev/sdc (10GiB)

Node 2 configuration

  • Hostname: IMAMSSQL-2
  • Public IP: 192.168.4.22
  • Private IP: 10.1.4.22
  • /dev/sdb (10GiB)
  • /dev/sdc (10GiB)

Virtual IP used for SQL Access

  • 168.4.20, this will be protected by LifeKeeper and “floats” between nodes

Operating System

  • CentOS 7.6

SQL Database Configuration

  • SQL Database:
  • SQL Virtual Hostname: IMAMSSQL
  • SQL Virtual IP: 192.168.4.20

SQL File System Mount Points

  • /database/data
  • /database/xlog

PREPARE SYSTEM FOR INSTALLATION

Installing MS-SQL

Initial SQL install

In this section we will add the Microsoft package location into our Linux OS and then instruct the OS to install SQL Server.

  1. Open the following Microsoft guide to installing SQL Server:
    https://docs.microsoft.com/en-us/sql/linux/sql-server-linux-setup?view=sql-server-ver15
  2. Login with root privilege or you use sudo before each command
  3. curl -o /etc/yum.repos.d/mssql-server.repo
    https://packages.microsoft.com/config/rhel/7/mssql-server-2017.repo
  4. yum install -y mssql-server
  5. /opt/mssql/bin/mssql-conf setup, I installed my SQL Server with an Evaluation license
  6. yum install -y mssql-tools unixODBC-devel
  7. echo ‘export PATH=”$PATH:/opt/mssql-tools/bin”‘ >> ~/.bash_profile
  8. echo ‘export PATH=”$PATH:/opt/mssql-tools/bin”‘ >> ~/.bashrc
  9. source ~/.bashrc
  10. systemctl stop mssql-server.service, we stop the SQL service and cannot start the SQL service
    until we have configured the disks used as storage in the section titled
    “Create database and transaction log file-systems and mount points”.
  11. /opt/mssql/bin/mssql-conf set filelocation.masterdatafile /database/data/master.mdf
  12. /opt/mssql/bin/mssql-conf set filelocation.masterlogfile /database/xlog/mastlog.ldf

Create database and transaction log file-systems and mount points

We will use the xfs file-system type for this installation. Refer to LifeKeeper supported file-system types to determine which file-system you want to configure. Make sure you configure the disk to use GUID identifiers. Here we will partition and format the locally attached disks; mount, create and permission the database locations we want SQL to use, finally we will start SQL which will create new Master DB and transaction logs in the location we specified. Note when creating the partition, DataKeeper requires the number of blocks in the partition to be odd. E.g. 20973567 (end) – 2048 (start) = 20971519.

  1. fdisk /dev/sdb
  2. mkfs -t xfs /dev/sdb1
  3. fdisk /dev/sdc
  4. mkfs -t xfs /dev/sdc1
  5. mkdir /database; mkdir /database/data; mkdir /database/xlog
  6. chown mssql /database/; chgrp mssql /database/
  7. chown mssql /database/data/; chgrp mssql /database/data/
  8. chown mssql /database/xlog/; chgrp mssql /database/xlog/
  9. vi /etc/fstab
    1. Add /dev/sdb1 mounting to /database/data, e.g. /dev/sdb1 /database/data xfs defaults 0 0
    2. Add /dev/sdb1 mounting to /database/xlog, e.g. /dev/sdb1 /database/xlog xfs defaults 0 0
  10. mount /dev/sdb1
  11. mount /dev/sdc1
  12. chown mssql /database/data/; chgrp mssql /database/data/
  13. chown mssql /database/xlog/; chgrp mssql /database/xlog/
  14. systemctl start mssql-server.service, we start the SQL service now that local disks are mounted
    – this will create new Master DB and transaction logs

Installing LifeKeeper

Refer to the Installation Guide
http://docs.us.sios.com/spslinux/9.5.1/en/topic/sios-protection-suite-for-linux-installation-guide

Create LifeKeeper Resource Hierarchies

Open the LifeKeeper GUI on the primary node:

# /opt/LifeKeeper/bin/lkGUIapp &

Communication Paths

Create backend and/or frontend IP routes, in our case backend is 10.2.4.21 & 22 and frontend is 192.168.4.21 & 22

  1. [AWS only] Right-click on each instance in the AWS Management Console and select Networking → Change Source/Dest. Check and ensure that source/destination checking is disabled.
  2. In the LifeKeeper GUI, click Create Comm Path.
  3. In the Remote Server(s) dialog, add the host names of the other cluster nodes and select them.

 

  1. Select the appropriate local (10.2.4.21) and remote (10.2.4.22) IP addresses.
  2. Repeat this process, creating communication paths between all pairs of remote nodes for each network (e.g., 12.0.1.30 and 12.0.2.30).  After completion, communication paths should exist between all pairs of cluster nodes.

IP Resources

The IP resource is the virtual IP that will be used to access the SQL server – in this case 192.168.4.20

  1. Verify that all of the virtual IP’s have been removed from the network interface by running
    ‘ip addr show’.
  2. Create the IP resource for the MSSQL virtual IP.
  3. In the LifeKeeper GUI, click Create Resource Hierarchy and select IP.

 

4. When prompted, enter the IP 192.168.4.20 and choose the subnet mask 255.255.0.0.

 

 

5. Enter a tag name such as ip-192.168.4.20-MSSQL.

DataKeeper Resources

This is the drives used to store the database and transaction logs, /database/data and /database/xlog

Data Replication Resources

  1. Ensure that all SQL file systems are mounted at the appropriate mount points under /database on the primary cluster node.
    # mount
    …
    /dev/sdb1 on /database/data type xfs (rw,relatime,attr2,inode64,noquota)

/dev/sdc1 on /database/xlog type xfs (rw,relatime,attr2,inode64,noquota)
…

2.Ensure that the file systems are not mounted on the backup cluster node(s).

3.  In the LifeKeeper GUI, click Create Resource Hierarchy and select Data Replication.

 

4. For Hierarchy Type, select Replicate Existing Filesystem.

5. For Existing Mount Point, select /database/data

6. Select the appropriate values for the rest of the creation dialogs as appropriate for your environment

Repeat steps 3-6 for the /database/data and /database/xlog file systems.

Quick-Service Protection

We will use LifeKeeper’s Quick Service Protection ARK to protect the mssql-server service, this will monitor the MSSQL service and make sure it’s running.

  1. Use systemctl status mssql-server.service on node 1 to ensure MSSQL is running
  2. Use systemctl status mssql-server.service on node 2 to ensure that MSSQL isn’t running, if it is then you will need to stop the service using systemctl stop mssql-server.service, then unmount the /database/data and /database/xlog directories.
  3. In the LifeKeeper GUI, click add resource
  4. Select the QSP ARK from the drop-down
  5. When the list of services available populates, choose mssql-server.service
  6. Select the appropriate values for the rest of the creation dialogs as appropriate for your environment
  7. Extend the hierarchy to node 2
  8. At the linux CLI on node 1, run “/opt/LifeKeeper/bin/lkpolicy -g –v”, output will look similar to this:
  9. If LocalRecovery: On is set for QSP-mssql-server then we need to disable local recovery on both nodes, this is done by executing (on both nodes):
  10. /opt/LifeKeeper/bin/lkpolicy -s LocalRecovery -E tag=”QSP-mssql-server”
  11. Confirm that Local Recovery is disabled on both nodes, “/opt/LifeKeeper/bin/lkpolicy -g –v” :

Reproduced from SIOS

New Product Release: SIOS Protection Suite for Linux 9.5.1

by Leave a Comment

New Product Release: SIOS Protection Suite for Linux 9.5.1

SIOS is continually updating our products to meet our customer’s evolving needs for high availability for mission-critical applications. We are excited to announce the general availability of SIOS Protection Suite for Linux version 9.5.1!  This release features adds support for a wider range of platforms and enhancements to our command-line interface feature.

New Product Release: SIOS Protection Suite for Linux 9.5.1

Key updates include

      • Support for the following operating systems and platforms: VMware Vsphere 7 , Red Hat Enterprise Linux (RHEL) 8.2 , Oracle Linux 8.2 , CentOS 8.2, SUSE Linux Enterprise (SLES) 12 SP5, RHEL 7.8 , CentOS 7.8 , Oracle Linux 7.8 , SLES 15 SP2
      • CLI Auto Install with enhanced setup script –  for faster, easier implementation
      • Expanded CLI support for ARKs and Cloning – enables simple, consistent deployment of multiple clusters

Reproduced with permission from SIOS