SIOS SANless clusters - SIOS SANless clusters High-availability Machine Learning monitoring

November 26, 2022	Create A Disaster Recovery Plan For Critical Applications Create A Disaster Recovery Plan For Critical Applications Business-critical applications can be anything from your database servers, to your SAP infrastructure. These are the applications your business relies on. Organizations can’t afford to have these applications down. In this episode, we sat down with Dave Bermingham, Director of Customer Success at SIOS Technology, to discuss how to build a concrete disaster recovery strategy for business-critical applications. Create A Disaster Recovery Plan For Critical Applications Reproduced with permission from SIOS
November 23, 2022	SAP on Azure High Availability Best Practices SAP on Azure High Availability Best Practices In the following video, Bala Anbalagan, senior SAP architect for Microsoft with 20 years of experience in SAP, explains the best practices for configuring high availability to protect SAP solutions in Azure. He also reviews the mistakes often made when implementing HA solutions in the cloud and key factors that users should know about when configuring SIOS LifeKeeper. Configuring SAP High Availability Solutions in the Cloud Bala explains that every SAP user should remember that a high availability solution is indispensable, especially in the cloud. Any cloud provider will need to make changes in their environments. Even though they have high service levels for their hardware infrastructure, there will be brief periods downtime that can bring your SAP systems down completely. It is also critical that users configure SAP HA properly. The main purpose of installing HA solutions is to protect against downtime, but if you don’t do it properly, you are just wasting time and money, regardless of the cloud you’re running in. It is essential to follow the configuration rules of your cloud provider. If you misconfiguration your HA or fail to test failover and failback, it can result in a business disruption when you are least expecting it – particularly during a period of high-utilization. SIOS LifeKeeper can detect errors during the configuration process. For example, it sends warnings if you only configure a single communication channel, as you always want a redundant communication channel, or a secondary network connection, between the nodes in the HA cluster. If you use SIOS DataKeeper, it will also show warnings if something is wrong with the configuration during the replication process. What makes configuring SIOS straightforward? SIOS has a pretty straightforward configuration process. Basically, you just need LifeKeeper installed in each of your cluster nodes and you use different types of SIOS application-specific recovery kits (ARK) modules (that come with LifeKeeper) depending on the application you want to recover. Also, the process is very easy to follow with a straightforward GUI – intelligence is built in, and you don’t need to change the details of the GUI. It automatically detects most of the information, further simplifying the set up process. Knowing which ARK to use and how to use it is important in the configuring process. The ARK is a software module that provides application-specific intelligence to the LifeKeeper software. SIOS provides separate ARKs for different applications. For example, for SAP HANA, you install the SIOS SAP HANA ARK to enable LIfeKeeper to automate configuration steps, detect failures and manage a reliable failover for SAP HANA while maintaining SAP’s best practices. Biggest Mistakes in Implementing HA for SAP in Azure Users commonly implement HA for SAP solutions in Azure with the same process as they do in an on-premises environment. They need to change their mindset. Always make sure to follow the recommendations provided by the cloud provider, that is, read documents and keep the parameters as recommended by the cloud providers. Another common mistake is adding too much complexity. Some customers put everything into a single cluster, but clusters should be separated for different servers. Making a cluster too large adds unnecessary complexity and potential risk. Thorough testing in every aspect is critical when it comes to HA clustering. Testing HA configurations before going live as well as periodically (and frequently) are the best things you can do to prevent unexpected downtime. Learn more about SAP high availability best practices in the video below or contact us to for more information about implementing high availability and disaster recovery for your essential applications in the cloud. Reproduced with permission from SIOS
November 20, 2022	The simple days of HA & DR are gone The simple days of HA & DR are gone Flipping through the TV channels I stumbled on the scene in the movie “He’s Just Not That Into You” with Drew Barrymore, saying what most of us in 2022 are feeling about Technology and especially high availability and disaster recovery: “I miss the days when you had one phone number and one answering machine and that one answering machine had one cassette tape and that one cassette tape either had a message from a guy or it didn’t. And now you just have to go around checking all these different portals just to get rejected by seven different technologies. It’s exhausting.” Sometimes, don’t you wish there was only one cloud or maybe even no cloud platform; one DB running on one OS; and only a front end application to worry about. But, the world has changed and is moving faster, and becoming more complicated. Advances in technology, the fallout of mergers and acquisitions, and the increasing appetites and pace of our 24/7 society, with billions of consumers looking for the latest deal and the best experience, means that the simple days are gone. 4 hard truths about your availability Your solution isn’t as simple as you think Of course your enterprise environment isn’t simple. You have legacy systems and applications, the kind that have been around almost since punch cards. You have new systems, made for the new generation of applications and databases. In addition you have solutions that were created a decade ago to bridge the gap or span the time between migrating from one platform to another, but despite your best efforts, these systems linger. Added to these challenges is a growing set of systems and IT resources from the merger and acquisition of Company U. Delivering HA is not as simple as you think in the new era. Bad architecture is a bigger problem than you realize As VP of Customer Experience, we’ve seen the damage caused by bad architecture. While deploying HA software can definitely help improve an application and database’s availability, HA software will never fully overcome incomplete requirements, poor networking, lack of redundant hardware, or other missing architectural components. Our team once worked with a customer to correct an undersized environment that left their system unstable during peak operating times. Because of their bad architecture, which included networking and hardware instability, their teams frequently found themselves scrambling to recover from avoidable downtime issues. In order to have a complete and sound, highly available and resilient solution you will need to deploy great software as a part of a sound architecture. Your admins need more help than they’ll admit Developing an enterprise grade, highly available resilient HA solution, built on a solid architecture with the ability to grow is not a simple process. Designing and architecting for resilience, application and data availability is not as easy as grabbing a box of cake mix off the shelf. Throw in an array of tools, processes from different teams, a mixture of SLA’s, and the varieties of OS, applications, databases, and platforms and you have a recipe for needing help. Recently, I interviewed a 20 year veteran working in an enterprise support environment. He described how many of his peers, and even at times himself, have not been able to handle the weight of maintaining critical enterprise availability. Your admins, not only need help when they have been up since 2am dealing with a catastrophic, multi-system, multi-application, nearly complete data center collapse, but also in the day to day hard work of enterprise availability in one of the most technologically complex eras ever. Your solution may not be as highly available as you think “While public cloud providers typically guarantee some level of availability in their service level agreements, those SLAs only apply to the cloud hardware.” There are many other reasons for application downtime that aren’t covered by cloud provider SLAs including: Software issues and bugs Human errors Software failure System or application hangs As VP of Customer Experience we’ve seen a thing or two, including a denial of service attack caused by a failed exit in a recursion routine, system exhaustion, security software quarantine of healthy, critical applications, kernel panics, and virtual machines that randomly reboot. If your HA strategy is relying solely on the SLAs of your hypervisor, your solution may not be as highly available as you think. You need to protect critical applications with clustering software that can monitor and detect issues, respond to problems reliably, and if necessary move operations to a standby server to ensure that your products and services remain reliable and available when and where they are needed. Our single data center has become a series of cloud platforms, spanning dozens of data centers. Our skunk work application has become a part of the bevy of critical front end, middleware and backend solutions that we must manage across Windows, Linux, and a few different *Nix varieties. The march of technology means that our high availability has become more complex and requires better architecture. It also means that our teams need more help to manage it all, and if we aren’t careful it could mean that we remain vulnerable and exposed. Which of the four truths is your team facing most? Cassius Rhue, VP Customer Experience Reproduced with permission from SIOS
November 15, 2022	What Does the New Driver in SIOS LifeKeeper for Windows Do For You? What Does the New Driver in SIOS LifeKeeper for Windows Do For You? Making data protection in shared and SAN-less environments stronger for years to come. What does Coca-Cola, KitKat, SalesForce, and SIOS LifeKeeper for Windows have in common? Here are a few hints: Coca-Cola relaunched a campaign using product redesigns of its iconic brands to adapt to the future, specifically to focus on social themes. Kit-Kat rebranded its candy bar in the UK to commemorate and celebrate the booming social media, YouTube, and general technology wave, and capitalize on the brand strength of the Android (KitKat) OS. Salesforce revamped its base product to create a sleeker, more modern, and faster interface to serve its customer’s needs. These companies made significant improvements to their iconic products, services and solutions to better serve their customers, adapt and prepare for the future, and capitalize on their strengths. In a similar fashion, SIOS has made dramatic improvements to our SIOS LifeKeeper for Windows product. Prior to LifeKeeper for Windows version 8.9.0, shared storage functionality, including I/O fencing and drive identification and management was handled by the NCR_LKF driver. Starting with the SIOS LifeKeeper for Windows release version 8.9.0, SIOS Technology Corp. redesigned the shared storage driver architecture. Beginning with the current release, the NCR_LKF driver has been removed and replaced by the SIOS ExtMirr driver, the engine behind the SANless storage replication of SIOS DataKeeper / SIOS DataKeeper Cluster Edition. Five significant benefits of the NCR_LKF architectural change in SIOS LifeKeeper for Windows: A more modern driver The ExtMirr driver provides a more modern filter driver to manage the shared storage functionality. While the NCR_LKF driver focused on “keeping the lights on” and the “data safe”, the architecture of the driver lagged behind more modern drivers. The ExtMirr driver maintains that data protection, while being more compatible, more modern, and more easily supported in newer versions of the Windows OS. More robust I/O fencing The driver used in both SIOS DataKeeper and SIOS DataKeeper Cluster Edition includes a robust fencing architecture. While the NCR_LKF driver was capable of I/O fencing, the new driver is more robust and has been tested in SAN and SANless environments. The enhanced I/O fencing leverages volume lock and node ownership information within the protected volume. Tighter integration and compatibility. Leveraging the I/O fencing for the ExtMirr driver used in the DataKeeper products means that the LifeKeeper for Windows solution increases in integration with the DataKeeper product line. The ExtMirr driver also includes the latest Microsoft driver signing and works seamlessly with Operating Systems that enforce driver signing and Secure Boot. Easier administration The ExtMirr driver gives customers and administrators a large set of command-line utilities for obtaining and administering the status of the volume. The emcmd commands are native to both of the SIOS DataKeeper products. They can now be used for easier administration with the SIOS LifeKeeper shared volume configurations. Customers and partners who leverage both shared storage and replicated configurations with the LifeKeeper for Windows products now have a single command line set of tools to know and use. The emcmd tools replace the previous volume.exe, volsvc, and similar NCR_LKF filter driver tools for administration (lock, unlock, etc). More frequent updates and fixes With the addition of the ExtMirr driver into SIOS LifeKeeper for Windows, the shared storage configurations, as well as replication configurations, will now see a boost in updates, new features, and fixes. While the NCR_LKF driver provided a solid foundation and stable base for I/O fencing, switching to the ExtMirr driver means that customers will see the same strength and stability, with faster updates for new product support Aligning the two products to a single driver may not be as flashy as the SalesForce Classic to Lightning update, but it adds significant functionality, increases the strength and longevity of both the SIOS DataKeeper and SIOS LifeKeeper solutions, and will make data protection in shared and SAN-less environments stronger for years to come. Cassius Rhue, VP Customer Experience Reproduced with permission from SIOS
November 11, 2022	How to recreate the file system and mirror resources to ensure the size information is correct How to recreate the file system and mirror resources to ensure the size information is correct When working with high availability (HA) clustering, it’s essential to ensure that the configuration of all nodes in the cluster are parallel with one another. These ‘mirrored’ configurations help to minimize the failure points on the cluster, providing a higher standard of HA protection. For example, we have seen situations in which the mirror-size was updated on the source node but the same information was not updated on the target node. The mirror size mismatch prevented LifeKeeper from starting on the target node in a failover. Below are the recommended steps for recreating the mirror resource on the target node with the same size information as the source: Steps: Verify – from the application’s perspective – that the data on the source node is valid and consistent Backup the file system on the source (which is the source of the mirror) Run /opt/LifeKeeper/bin/lkbackup -c to backup the LifeKeeper config on both nodes Take all resources out of service. In our example the resources are in service on node sc05 and sc05 is the source of the mirror (and sc06 is the target system/target of the mirror). In the right pane of the LifeKeeper GUI, right-click on the DataKeeper resource that is in service. Click Out of Service from the resource popup menu. A dialog box will confirm that the selected resource is to be taken out of service. Any resource dependencies associated with the action are noted in the dialog. Click Next. An information box appears showing the results of the resource being taken out of service. Click Done. Verify that all resources are out of service and file systems are unmounted Use the command cat /proc/mdstat on the source to verify that no mirror is configured Use the mount command on the source to make sure the file system is no longer mounted Use /opt/LifeKeeper/bin/lcdstatus -q on the source to make sure the resources are all OSU. In the LifeKeeper GUI break the dependency between the IP resource (VIP) and the file system resource (/mnt/sps). Right click on the VIP resource and select Delete Dependency. Then, select the File System resource (/mnt/sps) for the Child Resource Tag. This will result in two hierarchies, one with the IP resource (VIP) and one with the file system resource (/mnt/fs) and the mirror resource (datarep-sps). Delete the hierarchy with the file system and mirror resources. Right click on /mnt/sps and select Delete Resource Hierarchy. On the source, perform ‘mount <device> <directory>’ on the file system. Example: mount /dev/sdb1 /mnt/sps Via the GUI recreate the mirror and file systems via the following: Recovery Kit: Data Replication Switchback Type: Intelligent Server: The source node Hierarchy Type: Replicate Existing Filesystem Existing Mount Point: <select your mount point>. It is /mnt/sps for this example. Data Replication Resource Tag: <Take the default> File System Resource Tag: <Take the default> Bitmap File: <Take the default> Enable Asynchronous Replication: Yes Once created, you can Extend the mirror and file system hierarchy: Target server: Target node Switchback Type: Intelligent Template Priority: 1 Target Priority: 10 Once the pre-extend checks complete select next followed by these values: Target disk: <Select the target disk for the mirror>. It is /dev/sdb1 in our example. Data Replication Resource Tag: <Take the default> Bitmap File: <Take the default> Replication Path: <Select the replication path in your environment> Mount Point: <Select the mount point in your environment>. It is /mnt/sps in our example. Root Tag: <Take the default> When the resource “extend” is done select “Finish” and then “Done”. In the LifeKeeper GUI recreate the dependency between the IP resource (VIP) and the file system resource (/mnt/sps). Right click on the VIP resource and select Create Dependency. Select /mnt/sps for the Child Resource Tag. At this point the mirror should be performing a full resync of the size of the file system. In the LifeKeeper GUI in the right pane of the LifeKeeper GUI, right-click on the VIP resource. Select “In Service” to restore the IP resource (VIP), select the source system where the mirror is in service (sc05 in our example) and verify that the application restarts and the IP is accessible. Reproduced with permission from SIOS