SIOS SANless clusters

SIOS SANless clusters High-availability Machine Learning monitoring

  • Home
  • Products
    • SIOS DataKeeper for Windows
    • SIOS Protection Suite for Linux
  • News and Events
  • Clustering Simplified
  • Success Stories
  • Contact Us
  • English
  • 中文 (中国)
  • 中文 (台灣)
  • 한국어
  • Bahasa Indonesia
  • ไทย

DataKeeper UI vs. Car Dashboards: A Guide to High Availability Monitoring

August 24, 2024 by Jason Aw Leave a Comment

DataKeeper UI vs. Car Dashboards A Guide to High Availability Monitoring

DataKeeper UI vs. Car Dashboards: A Guide to High Availability Monitoring

Besides sharing the enjoyment of using DataKeeper Cluster Edition with its high availability and disaster recovery capabilities, most of us have something else in common . . . we drive a car … electric, gasoline or a hybrid.  As of 2022, Forbes states that 92% of households owned at least one car.

And those millions of cars have a few things in common with DataKeeper . . .

A dashboard with status indicators.

In DataKeeper’s case, the user interface (DataKeeper.msc) has what are known as Mirror Definitions or Mirror Status.

In cars, indicators are  affectionately known as “dashboard lights” or for some of you Gen(eration) Xers may call them “idiot lights”

Let’s jump right in and talk about the similarities.

All cars have some level of combustion (fuel), electric (or not) and cooling abilities; thus the associated lights on the dashboard are usually in the colors of Red, Yellow and Green.  Like a car dashboard, the DataKeeper UI has the “traffic light” schema in the Console Tree.

As we mentioned, the possible scenarios in troubleshooting a car, e.g. battery, fuel problems, engine overheating, like that of your engine, DataKeeper troubleshooting too can be consolidated to the following areas of:

  • Storage
  • Network
  • Other (Security, User Administration,etc.)

Referencing back to the “traffic light” identifiers in the Console Tree on the DataKeeper UI, let’s take a look “under the hood” to identify the state of the Mirror(s).

As a driver would take their car in for either to fix a problem or perform regular service, the dealership’s Technical Advisor or Service Technician, will plug in a OBD connector (On-board Diagnostic) to get a general idea of where the problem may be occurring (combustion, electrical or other)

Identify Mirror Status Colors to Diagnose DataKeeper Issues

As a user that’s supporting/driving DataKeeper, your first level of triage should be to identify those “color” changes of the mirror to confirm if Storage, Network or Other have been impacting users, performance, etc.

Those identifiers are affectionately called Mirror definitions. The mirror status, similar to the OBD, can be identified by launching a command called “emcmd . getmirrorvolinfo <drive letter>“.

Note:

To get to the “emcmd” commands, (which, by the way, stands for Extended Mirroring Command), we can launch an elevated (Administrator) command prompt as follows:

  • “cd %extmirrbase%”
    • This is a shortcut to the installation path for where the utilities are located e.g. <root>\Program Files (x86)\SIOS\DataKeeper

The output will be displayed as “# hostname #”

The 1st integer represents the role of the Mirror, (1 = Source, 2 = Target)

As for the Last integer, there are 6 states a Mirror can obtain:

1 – Mirroring (Green)

2 – Mirror is Resyncing (Yellow)

3 – Mirror is Broken (Red)

4 – Mirror is Pause (Yellow)

5 – Resyc is Pending (Yellow)

With several variations – just as it pertains to your car or DataKeeper – one must obtain a starting point to identify the “pain points”

  • Driver: Do you share the car with your family? Did someone leave a dome light on? Did the fuel type change from 94 octane to 87?
  • DataKeeper Administrator:  Are you the sole Support person?  Do other departments have access to your cluster, e.g. Database Administrators, Infrastructure Personnel responsible for Storage, Network and other?

Looking under the Hood: Preventive Steps to Take Before You Scale your Clustered Resources

Storage

Do your homework. Infrastructure and Database Administrators want to scale their storage to meet growing demands. They are very knowledgeable about the tasks at hand but if performed incorrectly or in the wrong order, the Mirror colors in DataKeeper could be Red, Yellow or none. See our documentation and supporting video on How to Properly Resize Your Storage.

Network

Easily avoid full resynchs. Infrastructure and database admins may want to segment existing mirror(s) traffic to a different network without any downtime or loss of High Availability. Can you imagine not having HA for re-creating a new mirror and having to perform a FULL Resync for a couple of Terabytes or even a Petabyte of data?  See our documentation and supporting video on how this can be achieved with ease

Other (Security)

Understand password management. Password policies may change via prescribed timeframes in Active Directory. If this is unbeknownst to the Administrators, and if the SIOS DataKeeper Service is restarted, the password that has been changed for the SIOS DataKeeper Service account (Active Directory) is NOT propagated automatically. Therefore a manual update of the Service Account Password is required within the Service applet. (services.msc)  For proper usage of SIOS DataKeeper Service Accounts view our supporting documentation 

Managing DataKeeper Across Multiple Departments to Avoid Downtime

Your car can have multiple drivers, different Service Technicians, different road conditions and the like. DataKeeper is no different as there may be cross-functional departments that are responsible for Storage, Network, Security and other, that could adversely impact DataKeeper. There may be related clustered resources that have relationships/dependencies with DataKeeper.These departments perform tasks without the DataKeeper Administrator’s knowledge and just like the dashboard lights in your cars, your mirrors will display those “traffic light” colors; noticeably Yellow and Red.

Checklist for Monitoring DataKeeper Mirror Status and Infrastructure Changes

  • Review “Traffic Light” colors
  • Identify status of the Mirrors via emcmd . getmirrorvolinfo command
  • If multiple departments are involved, ask about changes or scheduled events throughout the infrastructure albeit Storage, Network, Security or other
  • Augment your initial triage via Event Viewer logs, ipconfig /all output, dkhealthcheck, just to name a few

Contact SIOS Support for DataKeeper Issues

If your car has gone “kaput” and left you on the side of the road, you’ll likely reach out to AAA and they’ll provide a tow truck.
If you have concerns about your clustered DataKeeper Volume Resource, contact SIOS Support. Got a question or a non-priority issue, email us at support@us.sios.com. If your issue is urgent, call us at  877-457-5113.

Reproduced with permission from SIOS

Filed Under: Clustering Simplified Tagged With: High Availability

Webinar: Empowering Education: Enhancing System Availability with SIOS Solutions

August 18, 2024 by Jason Aw Leave a Comment

Empowering Education Enhancing System Availability with SIOS Solutions

Webinar: Empowering Education: Enhancing System Availability with SIOS Solutions

Register for the On-Demand Webinar

Navigating the challenges of modern education requires more than just innovative teaching methods; it demands robust technological support.

This webinar discusses the pivotal roles of High Availability (HA) and Disaster Recovery (DR) in ensuring uninterrupted learning experiences. Discover how institutions can effectively manage peak seasons, cater to global student demographics, and handle potential system failures. With a special spotlight on SIOS high availability solutions, learn how to build a resilient, cost-effective, and user-friendly IT infrastructure.

Reproduced with permission from SIOS

Filed Under: Clustering Simplified Tagged With: High Availability and DR, SIOS Datakeeper, SQL Server, Windows

Webinar: Exploring the Benefits of Single Server Protection High Availability

August 14, 2024 by Jason Aw Leave a Comment

Exploring the Benefits of Single Server Protection High Availability

Webinar: Exploring the Benefits of Single Server Protection High Availability

For most organizations, maintaining reliable uptime and continuity is crucial, especially for business essential applications. But what about your other applications? It is important to consider applications with less criticality and plan for improving their availability. Single Server Protection High Availability is the solution.

Watch this on-demand webinar to learn about Single Server Protection High Availability (SSP-HA), how it differs from other HA solutions and how to leverage it in your IT environment.

Reproduced with permission from SIOS

Filed Under: Clustering Simplified Tagged With: High Availability and DR, Single Server Protection, SQL Server, Windows

How to Perform Performance Testing Replication with SIOS DataKeeper

August 10, 2024 by Jason Aw Leave a Comment

How to Perform Performance Testing Replication with SIOS DataKeeper

How to Perform Performance Testing Replication with SIOS DataKeeper

Configuring replication for a production database can be a pretty daunting task especially if you have not done your research in advance. This blog will cover many parts of the trickiest aspect of setting up your environment properly… performance. Understanding these key points will put you ahead of the pack and ensure your production Go-Live does not have any last minute hiccups.

The first and most basic point to consider is choosing the correct mirror type for your configuration. SIOS DataKeeper comes with two options for mirror type during the creation process, Synchronous and Asynchronous. Either of these options have their own benefits and drawbacks depending on your environment.

Selecting Mirror Type

Synchronous mirrors excel best in LAN environments with high speed connections and provide 1:1 write consistency at time of commit to the primary system. However if the network, or target storage is unable to keep up with the throughput of the primary system you will see reduction in write speed to maintain synchronous write consistency. Therefore synchronous mirroring would not be recommended for WAN or high latency environments.

Asynchronous mirrors however are perfect for a WAN environment. Asynchronous mirrors provide all the same functionality of ensuring 1:1 write consistency between the nodes, but the difference is that writes are committed to the primary system before the write is committed to the target system. This is possible due to the utilization of a bitmap also known as an intent log, a bitmap tracks all of the changes that occur on the system at a block level and writes data to the target as quickly as it can through a backlog known as a write queue. The write queue can be limited by number of writes or total MB in data and when the limit is hit the mirror will pause and the data will sync, preventing a failover while the data is not in sync.

Hardware Configuration:

Now that you have decided which mirror type fits your environment best it is important to understand that DataKeeper is not magic, DataKeeper can only write and replicate as fast as your systems allow so having hardware capable of achieving the throughput needed by your applications is crucial. Here is some advice and tips for ensuring you have the hardware needed to achieve your replication goals.

  1. Ensure that your Primary and Target systems have identical storage hardware. For example target IOPS should be equal to the source IOPS. Otherwise the slowest component in the environment will prove to be the bottleneck of the write speed. Matching hardware will always provide better performance.
  2. Understanding the importance of the bitmap, the easiest and cheapest way to provide a significant boost in performance is to store the bitmap on its own dedicated high speed storage. The bitmap is very small so provisioning a 5 or 10GB SSD will be sufficient and provide great return on performance
    enhancement.
  3. Test the standalone hardware with an understanding that replicating data will introduce some overhead. For example if you have a requirement to attain 10,000 IOPS in your environment, ensure that your hardware can at a bare minimum attain consistent 10,000 IOPS standalone on all nodes that will be part of the cluster. If you are intending to perform synchronous mirroring ensure that you have beyond the bare minimum requirements as further overhead is introduced to maintain synchronous consistency. Network will also need to be load tested to ensure you can transfer the data required for your replication scheme.
  4. Know how to test properly. When utilizing a test environment to verify production capabilities it is important to mimic the setup as closely as possible. It is understood that you cannot set up an entire production database clone just to test replication but utilizing the correct data generation tool can provide better indication of current performance capabilities. Diskspd is a free tool that can be used for some basic testing, but in the world of SQL, HammerDB provides a much better indicator of real world performance.

DiskSpd: https://github.com/microsoft/diskspd
HammerDB: https://www.hammerdb.com/

  1. Lastly we have DataKeeper tuning, there are configurable settings beyond the mirror type within DataKeeper. Modifying these is generally a bit more nuanced and best done under the advice of the SIOS support team. However if you have confirmed that all of the other recommendations are squarely in place then tuning some DataKeeper parameters may provide that last boost in performance needed to meet your required metrics. Some examples of tuning would be increasing the number of outstanding writes that can be in your write queue or modifying how often the bitmap file is flushed to disk.

Reproduced with permission from SIOS

Filed Under: Clustering Simplified Tagged With: performance, replication

Creating a SQL Server 2019 Cluster on GCP with SIOS DataKeeper

August 5, 2024 by Jason Aw Leave a Comment

Creating a SQL Server 2019 Cluster on GCP with SIOS DataKeeper

Creating a SQL Server 2019 Cluster on GCP with SIOS DataKeeper

Create a SQL Server 2019 Cluster on Google Cloud Platform (GCP) with our step-by-step guide. Using SIOS DataKeeper Cluster Edition for SANLess clustering, our guide simplifies the process with pre-scripted steps and builds on Google’s documentation for ease and consistency.

Reproduced with permission from SIOS

Filed Under: Clustering Simplified Tagged With: Google Cloud Platform, SIOS Datakeeper, SQL Server

  • « Previous Page
  • 1
  • …
  • 6
  • 7
  • 8
  • 9
  • 10
  • …
  • 104
  • Next Page »

Recent Posts

  • Transitioning from VMware to Nutanix
  • Are my servers disposable? How High Availability software fits in cloud best practices
  • Data Recovery Strategies for a Disaster-Prone World
  • DataKeeper and Baseball: A Strategic Take on Disaster Recovery
  • Budgeting for SQL Server Downtime Risk

Most Popular Posts

Maximise replication performance for Linux Clustering with Fusion-io
Failover Clustering with VMware High Availability
create A 2-Node MySQL Cluster Without Shared Storage
create A 2-Node MySQL Cluster Without Shared Storage
SAP for High Availability Solutions For Linux
Bandwidth To Support Real-Time Replication
The Availability Equation – High Availability Solutions.jpg
Choosing Platforms To Replicate Data - Host-Based Or Storage-Based?
Guide To Connect To An iSCSI Target Using Open-iSCSI Initiator Software
Best Practices to Eliminate SPoF In Cluster Architecture
Step-By-Step How To Configure A Linux Failover Cluster In Microsoft Azure IaaS Without Shared Storage azure sanless
Take Action Before SQL Server 20082008 R2 Support Expires
How To Cluster MaxDB On Windows In The Cloud

Join Our Mailing List

Copyright © 2025 · Enterprise Pro Theme on Genesis Framework · WordPress · Log in