SIOS APAC Portal

June 7, 2022	How Workloads Should be Distributed when Migrating to a Cloud Environment How Workloads Should be Distributed when Migrating to a Cloud Environment Determining how Workloads (nodes) should be distributed is a common topic of discussion when migrating to the public cloud with High Availability in mind. If workloads are located within an on-premise environment, more often than not the locations of these workloads are defined by the location(s) of established datacenters. In many cases choosing another location in which to host a workload is not an available option. With a public cloud offering there are a wide range of geographical regions as well as availability zones to choose from. An Availability Zone is generally analogous to one or more datacenters (physical locations) being located in the same physical region (e.g., in California). These datacenters may be located in different areas but are connected using high-speed networks to minimize connection latency between them. (Note that hosting services across several datacenters within an availability region should be transparent to the user). As a general rule, the greater the physical distance between workloads, the more resilient the environment becomes. It’s a reasonable assumption that natural disasters such as earthquakes won’t affect different regions at the same time (e.g., both U.S. west coast and east coast at the same time). However, there is still a chance of experiencing service outages across different regions simultaneously due to system-wide failures (some cloud providers have previously reported simultaneous cross-region outages such as in the US & Australia). It may be appropriate to consider creating a DR (disaster recovery) plan defined across different cloud providers. Another perspective worthy of consideration is the cost to protect the resources. Generally the greater the distance between workloads, the more costs are incurred for data transfer. In many cases, data transfer between nodes within the same datacenter (Availability Zone) is free while it might costs $0.01/GB or more to transfer data across Availability Zones. This additional cost might be doubled (or more) when data is transferred across regions (i.e. $0.02 / GB). In addition, due to the increased physical distance between workloads, greater data latency between nodes should be anticipated between locations. Through consideration of these factors, generally speaking, it is recommended to distribute workloads across Availability Zones within the same Region. Reproduced with permission from SIOS
June 3, 2022	Benefits of SIOS Protection Suite/LifeKeeper 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
May 29, 2022	SIOS Protection Suite/LifeKeeper for Linux – Integrated Components SIOS Protection Suite/LifeKeeper for Linux – Integrated Components SIOS Protection Suite includes the following software components to protect an organization’s mission-critical systems. SIOS LifeKeeper SIOS LifeKeeper provides a complete fault-resilient software solution that enables high availability for servers, file systems, applications, and processes. LifeKeeper does not require any customized, fault-tolerant hardware. LifeKeeper simply requires two or more systems to be grouped in a network and site-specific configuration data is then created to provide automatic fault detection and recovery. In the case of a failure, LifeKeeper migrates protected resources from the failed server to a designated standby server. Users experience a brief interruption during the actual switchover. However, LifeKeeper restores operations on the standby server without operator intervention. SIOS DataKeeper SIOS DataKeeper provides an integrated data replication capability for LifeKeeper environments. This feature enables LifeKeeper resources to operate in shared and non-shared storage environments. Application Recovery Kits (ARKs) Application Recovery Kits (ARKs) include tools and utilities that allow LifeKeeper to manage and control a specific application or service. When an ARK is installed for a specific application, LifeKeeper is able to monitor the health of the application and automatically recover the application if it fails. These Recovery Kits are non-intrusive and require no changes within the application in order for it to be protected by LifeKeeper. There is a comprehensive library of ‘off-the-shelf’ Application Recovery Kits available as part of the SIOS Protection Suite portfolio. The types and quantity of ARKs supplied vary based on the edition of SIOS Protection Suite purchased. Reproduced with permission from SIOS
May 25, 2022	High Availability, RTO, and RPO High Availability, RTO, and RPO High availability (HA) is an information technology term that refers to a computer software or component that is operational and available for more than 99.99% of the time. End users of an application, or system, experience less than 52.5 minutes per year of service interruption. This level of availability is typically achieved through the use of high availability clustering, a configuration that reduces application downtime by eliminating single points-of-failure through the use of redundant servers, networks, storage, and software. What are recovery time objectives (RTO) and recovery point objectives (RPO)? In addition to 99.99% availability time, high availability environments also meet stringent recovery time and recovery point objectives. Recovery time objective (RTO) is a measure of the time elapsed from application failure to restoration of application operation and availability. It is a measure of how long a company can afford to have that application down. Recovery point objectives (RPO) are a measure of how up-to-date the data is when application availability has been restored after a downtime issue. It is often described as the maximum amount of data loss that can be tolerated when a failure happens. SIOS high availability clusters deliver an RPO of zero and an RTO of minutes. What is a high availability cluster? In a high availability cluster, important applications are run on a primary server node, which is connected to one or more secondary nodes for redundancy. Clustering software, such as SIOS LifeKeeper, monitors clustered applications and dependent resources to ensure they are operational on the active node. System level monitoring is accomplished via intervallic heartbeats between cluster nodes. If the primary server fails, the secondary server initiates recovery after the heartbeat timeout interval is exceeded. For application level failures, the clustering software detects that an application is not available on the active node. It then moves the application and dependent resources to the secondary node(s) in a process called a failover, where operation continues and meets stringent RTOs. In a traditional failover cluster, all nodes in the cluster are connected to the same shared storage, typically a storage area network (SAN). After a failover, the secondary node is granted access to the shared storage, enabling it to meet stringent RPOs. Reproduced with permission from SIOS
May 21, 2022	SIOS Protection Suite for Linux Evaluation Guide for AWS Cloud Environments SIOS Protection Suite for Linux Evaluation Guide for AWS Cloud Environments Get Started Evaluating SIOS Protection Suite for Linux in AWS Use this step-by-step guide to configure and test a two-node cluster in AWS to protect resources such as Oracle, SQL Server, PostgreSQL, NFS, SAP, and SAP HANA. Before You Begin Your Evaluation Review these links to understand key concepts you’ll need before you begin your failover clustering project in AWS. High Availability, RTO, and RPO – Gain a clear understanding of the fundamental concepts of HA. SIOS Protection Suite for Linux – Integrated Components – Understand the components included in SIOS Protection Suite: SIOS LifeKeeper, DataKeeper and application recovery kits/ Benefits of SIOS Protection Suite for Linux – Learn how SIOS Protection Suite for Linux provides superior data protection How Workloads Should be Distributed when Migrating to a Cloud Environment – Unlike on=premises environments, public cloud offerings give you a wide range of geographical regions availability zones to choose from when deploying your workloads. Learn best practices for choosing a workload distribution strategy for the cloud. Public Cloud Platforms and their Network Structure Differences – Public cloud providers have their own networking structures. Learn the basics of how these structures affect your cluster configuration. How a Client Connects to the Active Node – Learn the key clustering mechanisms that detect and manage the response to application failures. How does Data Replication between Nodes Work? – Ensuring redundancy of storage is essential. Learn how SIOS DataKeeper efficiently replicates data between nodes. What is “Split Brain” and How to Avoid It Learn how to ensure you maintain one active node and one or more standby node(s) even when the network connection fails. Configuring Network Components This section outlines the computing resource required for each node, the network structure and the process required to configure these components. Learn how to configure network components for failover clustering Network Structure Used in this Tutorial Compute Resources Used in this Tutorial Creating an Instance on AWS EC2 from Scratch Creating an Instance on AWS from Scratch Switching between AWS Services Deciding on an AWS Region Creating the VPC Creating a Subnet Creating an Internet Gateway and Assigning it to the VPC Creating the Route Table Creating a Security Group Creating the First EC2 Instance Creating the Second and Third Instances Configure Linux Nodes to Run SIOS Protection Suite for Linux Configure Linux Nodes to Run SIOS Protection Suite for Linux Install SIOS Protection Suite for Linux Install SIOS Protection Suite for Linux Login and Basic Configuration Login and Basic Configuration Protecting Critical Resources Creating an IP Resource in an On-premises Environment Switching between Nodes in a Cloud Environment Once the IP resource is protected, initiate a switchover (where the “standby” node becomes the “active” node) to test the functionality. How to Switch to Standby Node to Confirm Switchover is Working Protecting an Oracle Resource Protecting MSSQL Using Quick Service Protection Protecting a PostgreSQL Resource Protecting an NFS Resource Protecting SAP Resources Protecting SAP HANA Resources Reproduced with permission from SIOS

Results 211-215 of 959
< Page 43 of 192 >

Join Our Mailing List

First Name Last Name Email Address
Search