SIOS SANless clusters - Page 32 of 188 - SIOS SANless clusters High-availability Machine Learning monitoring

November 1, 2022	Installing SAP MaxDB in an HA Environment Installing SAP MaxDB in an HA Environment General SAP documentation on MaxDB is here: https://maxdb.sap.com/documentation/ MaxDB is a relational database management system (RDBMS) sold by SAP for large environments (SAP and non-SAP) that require enterprise-level database functionality. The first step to delivering high availability for any application is ensuring it is installed according to best practices. This blog provides important insight for installing MaxDB in a SIOS LIfeKeeper for Linux high availability clustering environment. It includes links to detailed installation documentation provided by SAP. These instructions assume that you will perform the MaxDB installation steps on all nodes in your SIOS LifeKeeper cluster that will be “production” nodes. 1. Downloading the MaxDB software Use your SAP account to download latest MaxDB package, in my case 51054410_2 Upload the package to your Linux instance, in this case to /mnt/software/ and extract the file using SAPCAR with switches -xvf. cd into the “MaxDB_7.9___SP10_Build_05_” folder and then into “DATA_UNITS” and then finally “MAXDB_LINUX_X86_64” SAP document describing installation: https://maxdb.sap.com/doc/7_7/44/eb166db6f0108ee10000000a11466f/content.htm 2. Using the CLI Installer Run SDBINST, the MaxDB installation manager which will begin the installation process. Walk through the options, either specify the values or accept the defaults: Select 0 for all components. You will then be prompted for the installation name. Installation path, installation description, privatedata and a port number. This installations instance data location will be privatedata and the port number is the port that this instance will use while running, the default is 7200 for the first installation. If you need to uninstall, follow the steps in this SAP document: https://maxdb.sap.com/doc/7_8/44/d8fc93daba5705e10000000a1553f6/content.htm 3. GUI Installer To use the GUI installer, you will need to set up xauth and use xming (or similar X-Windows emulator), see https://superuser.com/questions/592185/how-do-i-get-x11-forwarding-to-work-on-windows-with-putty-and-xming Note that the graphics libraries may need to be fixed. Fix some library links, Newer Linux versions have newer graphics libraries with different names. We can still use the newer libraries but MaxDB expects the older names and so we will create symbolic links to these existing libraries with the names that MaxDB expects to find: ln /usr/lib64/libpangoxft-1.0.so.0 /usr/lib64/libpangox-1.0.so.0 ln /usr/lib64/libpng12.so.0 /usr/lib64/libpng.so.3 ln /usr/lib64/libtiff.so.5 /usr/lib64/libtiff.so.3 Now run setup: cd /mnt/software/MaxDB_7.9___SP10_Build_05_/DATA_UNITS/MAXDB_LINUX_X86_64/ .//SDBSETUP These templates simply pre-define parameters for the MaxDB that will be created as part of the installation. I used Desktop PC/Laptop simply because it’s aimed at small single user installations, You can change most of the parameters after installation completes. See this note for more details. By default the global owner user created while setting up MaxDB gets /bin/false added to its entry in /etc/passwd This addition is to restrict the account used for the MaxDB installation for security reasons e.g. you cannot login with this account. In our case we will use this user and we can change the entry in /etc/passwd to /etc/bash so that we can login and use the user that’s created for us in our example. 4. Setting up a database Once we have the actual MaxDB software installed, we need to create a database and then start that database. In this example I will call my database SPS and the default admin user will be dbm with the password dbm. sudo su – sdb dbmcli -s -R /sapdb/MAXDB/db db_create SPS dbm,dbm dbmcli -d SPS -u dbm,dbm user_put dbm PASSWORD=dbadmin This should drop you to a prompt like this “dbmcli on SPS>”, this means that you are connected to the SPS db as sdb and we will now configure some parameters required to run the database. param_startsession param_init OLTP param_put CAT_CACHE_SUPPLY 5000 param_put CACHE_SIZE 3000 param_put MAXDATAVOLUMES 5 param_put RUNDIRECTORYPATH /sapdb/MAXDB/run param_checkall param_commitsession param_addvolume 1 DATA /sapdb/MAXDB/data/DISKD0001 F 2560 param_addvolume 1 LOG /sapdb/MAXDB/log/DISKL001 F 2048 quit Now it’s time to start the DB: dbmcli -d SPS -u dbm,dbadmin db_start All the above param and dbmcli commands should output OK when you execute them. If they do not then generally they will give you a vague idea of what’s wrong. dbmcli -d SPS -u dbm,dbadmin util_connect dbm,dbadmin db_activate dba,dba dbmcli -d SPS -u dbm,dbadmin load_systab -u dba,dba -ud domain dbmcli -d SPS -u dbm,dbadmin sql_connect dba,dba sql_execute CREATE USER test PASSWORD test DBA NOT EXCLUSIVE medium_put data datasave FILE DATA 0 8 YES medium_put auto autosave FILE AUTO util_connect dbm,dbadmin backup_save data autosave_on Load_tutorial auto_extend on quit Ok, now we need to create a DEFAULT key to allow SPS-L to connect to the resource, this is done as follows: xuser -U sdb -d SPS -u dbm,dbadmin, make sure this is executed on all production nodes or make sure that you copy /home/sdb/.XUSER.62 to all production nodes. Once we have these items complete we can start the global DB listener using: /sapdb/programs/bin/sdbgloballistener start Once the global DB listener is running you should be able to connect to the DB using something like MaxDB Studio or SQL.
October 27, 2022	How to Install SybaselIQ (16.1) How to Install SybaselIQ (16.1) I created a partition on an attached drive to use as a place to extract and execute software installers, mounted on /mnt/software This document is a useful reference to use during the installation and configuration processes. Pay particular attention to the required support packages. Step 1: System Prep For this installation I used a second 500GB drive attached to the instance. I created the following partitions: Disk /dev/xvdf: 500 GiB, 536870912000 bytes, 1048576000 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: gpt Disk identifier: 691F3320-5AEE-CF43-802B-A121C0A27B7B Device Start End Sectors Size Type /dev/xvdf1 2048 419432447 419430400 200G Linux filesystem /dev/xvdf2 419432448 524290047 104857600 50G Linux filesystem /dev/xvdf3 524290048 528484351 4194304 2G Linux filesystem I created XFS filesystems on each of these partitions. I mounted the disks: /dev/xvdf1 to /mnt/software – 200GB of space to hold installation media etc /dev/xvdf2 to /opt/sybaseiq – 50GB to hold the Sybase IQ installation, this can be smaller e.g. 5GB /dev/xvdf3 to /opt/demodb – 2GB to hold the Sybase demo database The demo database requires csh and ksh to run the install script. You should install these as root with the command “yum install csh” and “yum install ksh”. This is for RHEL, other Linux distributions have different package installers, replace yum with whichever package installer is available. Step 2: Download Sybase IQ Download the Sybase install packages from SAP Copy the SybaseIQ rar files into /mnt/software Step 3: Install unrar Install the RAR/UNRAR tools, this is required to extract the RAR files that SAP so likes to use For RHEL, grab the package cd /mnt/software/ wget https://www.rarlab.com/rar/rarlinux-x64-5.6.1.tar.gz tar -zxvf rarlinux-x64-5.6.1.tar.gz cd rar cp -v rar unrar /usr/local/bin Unrar the SybaseIQ installer into /mnt/software/Sybase /usr/local/bin/unrar x 51052038_part1.exe /mnt/software/Sybase Step 4: Create Sybase Admin User Sybase recommends not installing IQ as root. Thus I created a new user called sapiq “useradd -g 4 -b /home -u 1500 sapiq”, group 4 on my system was the adm group “passwd sapiq”, change the password for the new sapiq user Edit /home/sapiq/.bashrc, add source “/opt/sybaseiq/SYBASE.sh” to this file and add /opt/sybaseiq/IQ-16_1/bin64/ to the PATH variable Edit /home/sapiq/.bash_profile, add source “/opt/sybaseiq/SYBASE.sh” to this file Step 5: Create location for SybaseIQ I created a second partition on the attached drive from above, Sybase IQ is <2GB – I made my drive 5GB just to be on the safe side. Mount this to your preferred location, I used /opt/sybaseiq “sudo chown sapiq.adm /opt/sybaseiq”, make sure that the sapiq user owns the installation directory Step 6: Running SybaseIQ Setup cd /mnt/software/Sybase/51052038/Sybase IQ Server 16.1/Linux on IA64 64bit/ ./setup.bin If you have your X-Windows display setup correctly this will automatically launch a GUI installer, if setup.bin doesn’t find an expected X-Display method then it will drop back to an interactive CLI installer. Introduction splash screen, simply select Next. This is the installation location, you can use the “choose” option to navigate to a folder or simply type in a path. I chose typical here, but if you have specific packages you want to omit or include then you may want to choose Custom. I will use an evaluation license for my demo. Agree to the license terms. You can verify that what you chose is what you want. Once you verify that your selections are correct, install will begin – this should take several minutes. Configure HTTP/HTTPS ports for the cockpit. Configure the Cockpit RMI port to use. Configure the Cockpit TDS port to use. After configuring the ports then we get asked if we want to install Cockpit, I assume we do. Assuming that everything was configured correctly then you should get a successful message. This concludes the installation of Sybase IQ. Uninstalling SybaseIQ If you want to uninstall Sybase IQ then you can use the uninstaller that get installed. This is found in <Sybase Path>/sybuninstall/IQSuite e.g. /opt/sybaseiq/sybuninstall/IQSuite and is called “uninstall”, run it as follows: /opt/sybaseiq/sybuninstall/IQSuite/uninstall Again, If X-Forwarding is correctly configured then you will get a GUI uninstaller, if not then you will once again get an interactive CLI. If we want to uninstall, then select Next. You can choose to remove just some features or in most cases I’d imagine you would want to perform a complete uninstall. The uninstaller lets us know what it’s going to remove. I selected to remove these user installed files too, because I wanted all the contents or /opt/sybaseiq removing. Step 7: Configuring the demo database Once you have installed Sybase IQ you will most likely want to configure the demo database so that we can use it with SIOS Lifekeeper. Ensure that your Database Server has a correct entry in /etc/hosts, in my case I added a VIP to my system and then created an entry in /etc/hosts using the hostname IMA-SYBASE. To install the demo, you need a location to install the database into e.g. /opt/demodb. You need to create this location and make sure it’s owned by the user who installed Sybase IQ. Change directory to that location e.g. “cd /opt/demodb”. Run script to install the demo db; you need to pass a dba name and a dba password, “/opt/sybaseiq/IQ-16_1/demo/mkiqdemo.sh -dba sapdba -pwd sapdba”. During the demo db installation, IQ is started and a database listener is started. You can use dbisql to test connectivity. You can use Tools->Test Connection to make sure that you have the right connection details. Once you successfully connect then you are ready to use SybaseIQ and your database. Reproduced with permission from SIOS
October 22, 2022	White Paper: High Availability Clusters in VMware vSphere without Sacrificing Features or Flexibility High Availability Clusters in VMware vSphere without Sacrificing Features or Flexibility Six key facts you should know about high availability protection in VMware vSphere Many large enterprises are moving important applications from traditional physical servers to virtualized environments, such as VMware vSphere in order to take advantage of key benefits such as configuration flexibility, data and application mobility, and efficient use of IT resources. Realizing these benefits with business-critical applications, such as SQL Server or SAP can pose several challenges. This paper explains these challenges and highlights six key facts you should know about HA protection in VMware vSphere environments that can save you money. Reproduced with permission from SIOS
October 18, 2022	High Availability Protection for Financial Services High Availability Protection for Financial Services Historically, financial services organizations ran critical applications on mainframes. However, today’s financial institutions may have critical workloads in a variety of configurations, from all on-premises, hybrid, and all in-cloud infrastructures depending on the server types and bandwidth available to accommodate these configurations. Learn how to plan and ensure applications and other related resources in HA/DR environments meet the organization’s needs for scalability, reliability, and configuration flexibility. Reproduced with permission from SIOS
October 14, 2022	How to use Azure Site Recovery (ASR) to replicate a Windows Server Failover Cluster (WSFC) that uses SIOS DataKeeper for cluster storage How to use Azure Site Recovery (ASR) to replicate a Windows Server Failover Cluster (WSFC) that uses SIOS DataKeeper for cluster storage Intro So you have built a SQL Server Failover Cluster Instance (FCI), or maybe an SAP ASCS/ERS cluster in Azure. Each node of the cluster resides in a different Availability Zone (AZ), or maybe you have strict latency requirements and are using Placement Proximity Groups (PPG) and your nodes all reside in the same Availability Set. Regardless of the scenario, you now have a much higher level of availability for your business critical application than if you were just running a single instance. Now that you have high availability (HA) covered, what are you going to do for disaster recovery? Regional disasters that take out multiple AZs are rare, but as recent history has shown us, Mother Nature can really pack a punch. You want to be prepared should an entire region go offline. Azure Site Recovery (ASR) is Microsoft’s disaster recovery-as-a-service (DRaaS) offering that allows you to replicate entire VMs from one region to another. It can also replicate virtual machines and physical servers from on-prem into Azure, but for the purpose of this blog post we will focus on the Azure Region-to-Region DR capabilities. Setting up Azure Site Recovery We are going to assume you have already built your cluster using SIOS DataKeeper. If not, here are some pointers to help get you started. Failover Cluster Instances with SQL Server on Azure VMs SIOS DataKeeper Cluster Edition for the SAP ASCS/SCS cluster share disk We are also going to assume you are familiar with Azure Site Recovery. Instead of yet another guide on setting up ASR, I suggest you read the latest documentation from Microsoft. This article will focus instead on some things you may not have considered and the specific steps required to fix your cluster after a failover to a different subnet. Paired Regions Before you start down the DR path, you should be aware of the concept of Azure Paired Regions. Every Region in Azure has a preferred DR Region. If you want to learn more about Paired Regions, the documentation provides a great background. There are some really good benefits of using your paired region, but it’s really up to you to decide on what region you want to use to host your DR site. Cloud Witness Location When you originally built your cluster you had to choose a witness type for your quorum. You may have selected a File Share Witness or a Cloud Witness. Typically either of those witness types should reside in an AZ that is separate from your cluster nodes. However, when you consider that, in the event of a disaster, your entire cluster will be running in your DR region, there is a better option. You should use a cloud witness, and place it in your DR region. By placing your cloud witness in your DR region, you provide resiliency not only for local AZ failures, but it also protects you should the entire region fail and you have to use ASR to recover your cluster in the DR region. Through the magic of Dynamic Quorum and Dynamic Witness, you can be sure that even if your DR region goes offline temporarily, it will not impact your production cluster. Multi-VM Consistency When using ASR to replicate a cluster, it is important to enable Multi-VM Consistency to ensure that each cluster node’s recovery point is from the same point in time. That ensures that the DataKeeper block level replication occurring between the VMs will be able to continue after recovery without requiring a complete resync. Crash Consistent Recovery Points Application consistent recovery points are not supported in replicated clusters. When configuring the ASR replication options do not enable application consistent recovery points. Keep IP Address After Failover? When using ASR to replicate to your DR site there is a way to keep the IP address of the VMs the same. Microsoft described it in the article entitled Retain IP addresses during failover. If you can keep the IP address the same after failover it will simplify the recovery process since you won’t have to fix any cluster IP addresses or DataKeeper mirror endpoints, which are based on IP addresses. However, in my experience, I have never seen anyone actually follow the guidance above, so recovering a cluster in a different subnet will require a few additional steps after recovery before you can bring the cluster online. Your First Failover Attempt Recovery Plan Because you are using Multi-VM Consistency, you have to failover your VMs using a Recovery Plan. The documentation provides pretty straightforward guidance on how to do that. A Recovery Plan groups the VMs you want to recover together to ensure they all failover together. You can even add multiple groups of VMs to the same Recovery Plan to ensure that your entire infrastructure fails over in an orderly fashion. A Recovery Plan can also launch post recovery scripts to help the failover complete the recovery successfully. The steps I describe below can all be scripted out as part of your Recovery Plan, thereby fully automating the complete recovery process. We will not be covering that process in this blog post, but Microsoft documents this process. Static IP Addresses As part of the recovery process you want to make sure the new VMs have static IP addresses. You will have to adjust the interface properties in the Azure Portal so that the VM always uses the same address. If you want to add a public IP address to the interface you should do so at this time as well. Network Configuration After the replicated VMs are successfully recovered in the DR site, the first thing you want to do is verify basic connectivity. Is the IP configuration correct? Are the instances using the right DNS server? Is name resolution functioning correctly? Can you ping the remote servers? If there are any problems with network communications then the rest of the steps described below will be bound to fail. Don’t skip this step! Load Balancer As you probably know, clusters in Azure require you to configure a load balancer for client connectivity to work. The load balancer does not fail over as part of the Recovery Plan. You need to build a new load balancer based on the cluster that now resides in this new vNet. You can do this manually or script this as part of your Recovery Plan to happen automatically. Network Security Groups Running in this new subnet also means that you have to specify what Network Security Group you want to apply to these instances. You have to make sure the instances are able to communicate across the required ports. Again, you can do this manually, but it would be better to script this as part of your Recovery Plan. Fix the IP Cluster Addresses If you are unable to make the changes described earlier to recover your instances in the same subnet, you will have to complete the following steps to update your cluster IP addresses and the DataKeeper addresses for use in the new subnet. Every cluster has a core cluster IP address. What you will see if you launch the WSFC UI after a failover is that the cluster won’t be able to connect. This is because the IP address used by the cluster is not valid in the new subnet. If you open the properties of that IP Address resource you can change the IP address to something that works in the new subnet. Make sure to update the Network and Subnet Mask as well. Once you fix that IP Address you will have to do the same thing for any other cluster address that you use in your cluster resources. Fix the DataKeeper Mirror Addresses SIOS DataKeeper mirrors use IP addresses as mirror endpoints. These are stored in the mirror and mirror job. If you recover a DataKeeper based cluster in a different subnet, you will see that the mirror comes up in a Resync Pending state. You will also notice that the Source IP and the Target IP reflect the original subnet, not the subnet of the DR site. Fixing this issue involves running a command from SIOS called CHANGEMIRRORENDPOINTS. The usage for CHANGEMIRRORENDPOINTS is as follows. emcmd <NEW source IP> CHANGEMIRRORENDPOINTS <volume letter> <ORIGINAL target IP> <NEW source IP> <NEW target IP> In our example, the command and output looked like this. After the command runs, the DataKeeper GUI will be updated to reflect the new IP addresses as shown below. The mirror will also go to a mirroring state. Conclusions You have now successfully configured and tested disaster recovery of your business critical applications using a combination of SIOS DataKeeper for high availability and Azure Site Recovery for disaster recovery. If you have questions, or would like to consult with SIOS to help you design and implement high availability and disaster recovery for your business critical applications like SQL Server, SAP ASCS and ERS, SAP HANA, Oracle or other business critical applications, please reach out to us. Reproduced with permission from SIOS