--- canonical: https://safekit.evidian.com/wp-content/uploads/downloads_safekit/version-82/slides-en/2-competition-en.pptx --- # PowerPoint Converted to Markdown Source: https://safekit.evidian.com/wp-content/uploads/downloads_safekit/version-82/slides-en/2-competition-en.pptx ## Slide 1: Evidian SafeKit Competition - Distinctive advantages ### Speaker notes > These slides are timed and automatically move from one to the next after a delay. To remove this automation: Go to 'Slide Show' and uncheck 'Use Timings’. > The slides have a soundtrack represented by an audio icon on the right side of each slide. To remove the soundtrack, click on each audio icon and lower the volume to the minimum. > I'm going to present the distinctive advantages of Evidian SafeKit against the competition. We will see that Evidian SafeKit stands out due to its simplicity, cost-effectiveness, and versatility, making it an ideal choice for enhancing application availability against failures. ## Slide 2 - Introduction ### Speaker notes > Let’s start with an introduction. ## Slide 3: Save costs with SafeKit: 3 in 1 product _No extractable slide text found._ ### Speaker notes > Let's compare SafeKit with traditional hardware clustering solutions. Hardware clustering generally involves three types of solutions. First, hardware load balancers, such as the F5 BIG-IP, are placed in front of a server farm to distribute TCP sessions to available servers. Second, to protect data from failures, the data is placed in shared storage on a SAN, which can be replicated between two disk arrays. Third, software like Microsoft failover cluster, monitor failover by reattaching the shared storage to a secondary server in case of a failure before restarting applications. > SafeKit is a versatile "3 in 1" product that offers load balancing, replication, and failover. This software-only solution does not require special skills or additional hardware, making it a simple and cost-effective choice. SafeKit works with standard editions of databases, Windows, and Linux, which further reduces costs. By integrating these three functionalities into one product, SafeKit simplifies deployment and management, providing a robust and efficient solution for various IT environments. ## Slide 4: The 3 Best Use Cases for SafeKit _No extractable slide text found._ ### Speaker notes > In the 3 best use cases of SafeKit, firstly, we have the OEM Software use case. A software publisher uses SafeKit as an OEM software for high availability of its application. This ensures that their applications remain available and reliable, even in the face of failures. > Next, we have the Distributed Enterprise use case. In this scenario, a distributed enterprise deploys SafeKit in many branches without requiring specific IT skills. This allows for seamless high availability across multiple locations, enhancing business continuity. > Lastly, we have the Remote Sites use case. SafeKit is deployed in two remote sites without the need for replicated bays of disks through a SAN. This provides a cost-effective solution for business continuity and disaster recovery. ## Slide 5: The 3 Worst Use Cases for SafeKit _No extractable slide text found._ ### Speaker notes > Now, let's consider the three worst use cases of SafeKit. > In the first worst-case scenario of SafeKit, large data volumes can lead to significant resynchronization times after a failure. With a 1 Gb/s network, it takes about 3 hours per terabyte, while a 10 Gb/s network reduces this to less than 1 hour. Using external shared storage is an alternative but more expensive and complex. > When dealing with over 1,000,000 files, resynchronization performance after a failure can be affected by the time required to check each file date between both nodes. A better approach is to place these files in the virtual hard disk of a virtual machine, simplifying the resynchronization process to a single file. > For full virtual machine replication, failover of more than 32 virtual machines is challenging, as each runs in an independent mirror module, with a maximum of 32 modules per cluster. > In the second worst-case scenario of SafeKit, a slow network can be problematic. Good latency, typically less than 2ms round-trip, and good bandwidth, typically 1 Gb/s or more, are essential for synchronous replication and resynchronization after a failure. For slow networks, asynchronous replication to a disaster recovery site is recommended with a backup solution and no automatic failover. > An extended LAN between remote sites is a perfect network solution for SafeKit as it offers the advantages of a fast network while also having the capability to reroute the server's IP address automatically without the need for load balancers. > In the third worst-case scenario of SafeKit, SafeKit's network load balancing is typically used with fewer than 10 servers and not with a large number of servers. ## Slide 6 - Virtual machine cluster ### Speaker notes > Let's now take a closer look at virtual machine clusters, exploring their architectures, benefits, and use cases. ## Slide 7: Hypervisor HA vs SafeKit - Hypervisor HA - VMs on a shared disk - Shared disk - Remote sites = replicated bays across a SAN or vSAN - Specific IT skills to configure the system - Large number of VMs - SafeKit with Hyper-V or KVM - VMs replicated and restarted by SafeKit - No shared disk (synchronous real-time replication instead) - Remote sites = no replicated SAN - No specific IT skills: 10mn to configure - Small number of VMs (<=32 VMs, a few Terabytes) ### Speaker notes > Firstly, let's talk about traditional virtual machine clusters. These solutions rely on shared disks with specific external bays of disks. The virtual machines are placed on the shared disks, and they are monitored and restarted automatically from another host and from the shared disk if a failure is detected. These solutions require a SAN (Storage Area Network) for implementing the shared storage, making them suitable for environments with extensive IT skills and the need for complex shared storage configurations. > In contrast, SafeKit offers a high availability solution that is simpler to implement compared to these solutions. One of the key differentiators is that SafeKit does not require a shared disk; instead, it uses synchronous real-time replication with no data loss. This makes it suitable for remote sites without the need for a SAN. SafeKit is limited to the replication and failover of 32 virtual machines and a few terabytes, which may be a consideration for larger deployments. However, it offers a straightforward configuration process and a cost-effective solution with no shared storage, making it accessible to a wider range of users. ## Slide 8 - Mirror cluster ### Speaker notes > Let's now consider the competition for the SafeKit mirror cluster with real-time replication and automatic failover. ## Slide 9: Hardware vs software cluster - Hardware clusters are complex - Standard Windows or Linux clustering - Special shared storage - Needs high level skills in OS and storage - Remote sites require replicated storage - Supports large volume of data - Software clusters are simple - SafeKit is a software-only solution - No special hardware - No specific skills - Remote sites simple with no extra cost - Supports only several Tera-bytes of data ## Slide 10: Asynchronous vs synchronous replication - Asynchronous replication - Do not wait acknowledgement of replicated IO - Data loss on failure - Automatic failover dangerous (not up-to-date data) - No automatic failback (manual operations) - Can work over a WAN - Synchronous replication - SafeKit waits acknowledgement of replicated IO - No data loss on failure - Automatic failover (up-to-date data) - Automatic failback with resynchronization of data - Requires latency/bandwidth of a LAN ### Speaker notes > Let's discuss the differences between asynchronous and synchronous replication. > Asynchronous replication operates by tracking write disk IOs on the primary server and sending them asynchronously over the network. The primary server does not wait for acknowledgments from the secondary server before proceeding. This means that any data not yet copied to the secondary server can be lost if the primary server fails. In particular, transactional applications may lose committed transactions in the event of a failure. > On the other hand, synchronous replication, as implemented by SafeKit, ensures that when a write disk IO is performed by the application on the primary server, SafeKit waits for acknowledgments from both the local disk and the secondary server before sending the acknowledgment back to the application. This mechanism is crucial for the failover of transactional applications, as it ensures no data loss and that all committed data on the primary server's disk is also present on the secondary server's disk. > Synchronous replication is necessary for high availability solutions with automatic application failover, whereas asynchronous replication is useful for backup solutions without automatic failover. The former requires a fast network such as a LAN, whereas the latter adapts to slower networks. ## Slide 11: Disk vs file replication - Block-level disk replication - Application data must be isolated in a special disk - Need reconfiguration of the application - Replication of a full disk - Prerequisite on disk organization - Complex deployment - Byte-level file replication - Application data can be anywhere with SafeKit - No need for application reconfiguration - Replication only of selected directories - No prerequisites on disk organization - Plug-and-play deployment ### Speaker notes > Let's discuss the differences between block-level disk replication and byte-level file replication. > Block-level disk replication, as the name suggests, involves replicating data at the disk level. This means that any changes made to the disk are replicated, including not only the application data but also the metadata used to manage the disk, such as the list of free blocks and file system internal information. > The disk-level replication has a significant impact on the organization of application data. All data must be localized within a special replicated disk, which requires reconfiguring the application. In some cases, it may be impossible to replicate data if they reside on the system disk, as this disk must remain specific to each server. Additionally, the recovery time increases due to the need for a file system recovery procedure on the replicated disk after a failover. > Now, let's move on to byte-level file replication. Byte-level file replication, such as that implemented by SafeKit, focuses on replicating only the modifications made within files. This means that only the changes generated by application activity are replicated, without including unnecessary metadata. Moreover, there is no impact on the organization of application data. Folders to replicate are just defined in SafeKit and there is no reconfiguration of application data even if they are in the system disk. > As you can see, the configuration of file-level replication is much simpler than disk-level replication. ## Slide 12: Fault tolerance vs high availability - Fault tolerant cluster - Both servers execute the same thing at the same time - Dedicated hardware - Software exception on both servers at the same time - CPU usage on both servers for the same application - In case of crash, application continues - High availability cluster - With SafeKit, both servers can run different applications - No dedicated hardware - Software exception recovery - Application restarted in a different OS environment - In case of crash, application is restarted ### Speaker notes > Let's now talk about the difference between fault tolerance and high availability. > Fault tolerance is a system's ability to continue operating without interrupting a critical application in case of failure. This is achieved through specialized hardware or hypervisors that detect hardware failures and instantly switch to a redundant server without restarting the application. Fault-tolerant systems are designed to handle hardware failures. However, they do not address software failures, which are the most frequent cause of system downtime. The primary advantage of fault tolerance is that it ensures zero recovery time in case of hardware failures since the application continues running on the secondary server without interruption. It's important to note that in fault-tolerant systems, the secondary server is dedicated to running the same application as the primary server, synchronized at the instruction level. > On the other hand, high availability, like SafeKit, focuses on minimizing downtime and ensuring that services remain accessible even in the event of hardware or software failures. High availability clusters typically consist of two servers that restart the critical application if a failure occurs. High availability solutions are more flexible as they can run on any type of server or hypervisor. They also support smooth upgrades and fixes, allowing different versions of applications and operating systems to coexist. The recovery time for high availability systems depends on the time it takes to detect and restart the application, usually around one minute, with zero data loss due to synchronous replication. The secondary server is not dedicated to restarting the application of the primary server; it can run other applications. This feature is particularly important in the SafeKit Hyper-V cluster where both servers are active and run different virtual machines with crossed replication and mutual failover. ## Slide 13 - Farm cluster ### Speaker notes > Let's now consider the competition for the SafeKit farm cluster with network load balancing and automatic failover. ## Slide 14: Hardware vs software load balancing - Hardware load balancing - External network boxes or dedicated servers for load balancing - Dedicated hardware - Load balancing but no failover toolkit and no real-time file replication - Needs high-level skills in networking - Large web farm - Supports servers in different subnets - Software load balancing - With SafeKit, installation on the application server side - No network box, no dedicated proxy server - Load balancing + a failover toolkit + real-time file replication - No specific skills required - Small web farm (typically <10 servers) - Requires servers in the same subnet ### Speaker notes > Hardware load balancers are commonly used to distribute network or application traffic across multiple servers. They ensure that no single server becomes overwhelmed with too many requests, thereby improving the overall performance and reliability of the system. However, the cost of hardware load balancers can be high, and they require advanced network skills to be configured. > Now, let's talk about the SafeKit farm cluster and its network load balancing features. > Firstly, SafeKit does not require any additional load balancers or dedicated proxy servers above the farm. It is installed directly on the application servers in the farm, using a standard virtual IP address and Ethernet MAC address for the load balancing. This setup works seamlessly with physical servers or virtual machines on both Windows and Linux, without any special network configuration or advanced skills. > Secondly, SafeKit does not implement only network load balancing on a virtual IP but all clustering features such as monitoring software failures, automatic application restart, and a replication option with a mirror module. Thus, SafeKit offers a uniform high availability solution for an N-tiers architecture with network load balancing and failover on frontends, and replication and failover on backends. Making that on Windows and Linux with a single product, using the same installation, configuration, and administration is unique in the market! ## Slide 15: Thank you ! - Contact us here