mirroring - cost effective solution
Our customer wants mirroring even on same network and it just increases the cost for us without helping much.
Are there better solution to avoid fake impression of HA?
Discussion (10)3
Log in or sign up to continue
https://community.intersystems.com/post/mirroring-cost-effective-solution
While I agree that ideally you'd run two IRIS nodes in two geographically close but fully separate datacenters, running IRIS in a mirror with both servers in the same datacenter still provides protection from:
In addition to that datacenters often allow users to specify placement strategy. Select spread placement strategy to avoid hosting both servers on the same underlying hardware if possible.
So mirroring in this scenario still provides a lot of advantages.
I 100% agree with Eduard.
Even back when I had two mirrored instances sat running in the same physical location, we were saved many times by mirroring when there had been issues with either IRIS or the server/OS itself.
It's also very helpful for managing upgrades, and even server migrations (by adding in the new servers as async members, and then demoting a failover member on an old server and promoting a new server from async to failover).
Things might be on the same network, but on virtual machines spread across different data centers / physical servers, so definitely some level of HA for sure if you have more than one instance. You got to take and work with what's available. If in future, that client has network separation also available then you can increase your level of HA, but not having HA isn't right.
if we run IRIS in the container, is there a documentation to handle mirroring?
Hello Jignesh,
I guess that you refer to a sync mirror (e.g. a failover pair: primary---backup). People here were mentioning unplanned down time (hardware and OS failures) but there is another advantage to benefit from a better HA for planned downtime for:
- IRIS maintenance => move a DB from disk to disk, split/move data from one DB to another
- Hardware maintenance => VM re-size, add/change data disks
- O/S maintenance => O/S patches, updates
Benefits:
1. All those activities are possible with 0 downtime (since the pair are 100% identical)
2. There is no data loss when there is a switch: either an automatic (due to failure) or manual (due to "planned" maintenance)
3. RTO - usually just a few seconds, depending on the complexity of your application/interoperability
4. Manual switch let you do the necessary work on the "backup", switch manually (e.g. make the "backup" a "primary") and do the same work on the other member.
I am wondering, if the following image depicts right design. Please assume IRIS deployed as a container. And what kind of minimum hardware configuration required to deploy dockerized IRIS 2024.x?
For IP address transfer/takeover to work the network has to be the same. Other clustering solutions work like this.
Planning a Mirror Virtual IP (VIP)
If by fake you mean not the normal OS level clustering solution that is true. It is an app specific solution.
If the cost of the 2x storage is an issue maybe a deduplicating SAN would reduce the cost at the added risk not having redundant storage.
We are going to use docker not the virtual machine and SAN is not possible as the installation happen on customer data center, so cost matters.
I also don't know if there is a packaging solution given by IRIS for dockerized setup (not Kubernetes).
Sounds much the same as these threads:
IRIS Mirror in the cloud (AWS)My opinion: IRIS Mirror not as reliable as expected in AWS Elastic Container ServiceSo what is the better solution for HA at the container level.