In March 2015, Amazon AWS announced they support S3 replication across regions. When a certain region in S3 goes offline, you can serve files from your mirror in another region.
The practice of keeping your infrastructure online by doing a switch over to another region is ...
What you are asking for is, basically, high-availability. In order to make a system highly available, you need three things:
Eliminate single points of failure
A mechanism to switch from an endpoint to another
A way to detect failures
Eliminate single points of failure
In the case of S3, the point #1 is addressed, as Evgeny pointed out, by S3 cross-region ...
The drawback when there's replication come from the note below:
Amazon S3 routes any virtual hosted–style requests to the US East
(N. Virginia) region by default if you use the US East (N. Virginia)
endpoint (s3.amazonaws.com), instead of the region-specific endpoint
(for example, s3-eu-west-1.amazonaws.com).
When you use replication you usualy let ...
Many big companies would be at fault for not using this feature. It does add additional cost, and historically any kind of real disaster recovery solution is untested even if implemented.
Other than the cost issue, companies who are actively using cross-region replication can offer a valid concern regarding the latency it takes for an object to replicate. ...
What your are describing can typically be addressed with a correct inventory design.
From there you can easily:
create plays that will target a group or ...
So, I know I’ve praised GitLab in my other answer to your questions before, but it really is awesome. They have a an HA solution called GitLab Geo. It’s primarily meant to speed up GitLab usage for geographically distributed teams, but the other main benefit is that the read-only secondary server can be easily promoted to be the master:
Best practices for replicating masters for HA clusters
Try to place master replicas in different zones. During a zone failure, all masters placed inside the zone will fail. To survive zone
failure, also place nodes in multiple zones (see multiple-zones for
This (slightly old in cloud years) question on Hacker News provides a few suggestions:
Remove the security groups from all instances in one zone, which should technically make them all appear 'down'
Adjust the VPC route tables to black hole the subnets in one availability zone
Disable an availability zone from the load balancer (docs)
You could also ...
Take a look at Gitea, https://gitea.io/en-US/, much easier to host yourself than Gitlab and you are in control if things go down. I think that by making the database backend HA you could roll out more Gitea frontends.
Another option to know about at least is Keybase private Git, https://keybase.io/blog/encrypted-git-for-everyone. Have not tried it or know ...
Your application requirements really do influence your options here, maybe add more detail about the app because this subject is very much about your application architecture too.
The application state is fixed, pod's are rebuilt as per the spec or source container that defines them and the replication sets take care of the deployment so I'd say the ...
As @XiongChiamiov mentioned, it's a very hard question to answer, but here's a clue:
Artifactory is a network-bond server. It means given enough storage, CPU and memory, it will max out your network interface first. Network interface is considered maxed out at half its rated bandwidth limitation. That can help you do the math.
There are docker images for running opensource databases in high availability mode such as https://info.crunchydata.com/blog/an-easy-recipe-for-creating-a-postgresql-cluster-with-docker-swarm
You can also find examples of Microsoft SQLServer container for Linux being run with high availability on Kubernetes https://docs.microsoft.com/en-us/sql/linux/...
This lab from AWS Well-Architected will show you how to implement an AWS AZ failure simulation using Bash, Java, Python, C#, or PowerShell
My choice would be design B.
It's true that the availability of the Vault would be crucial, but Jenkins' availability would similarly be crucial in design A. So from this perspective the decision would normally be driven by the comparison of the two availability figures, if available. Based on its functionality I suspect that Jenkins is likely to be a more ...
First a primer on regions and availability zones
Regions are physical places where the AWS resources are located. As such different regions may offer different resources. This is also important for latency-sensitive operations and data sovereignty laws. Having an EC2 instance in the us-east-1 region means all of my instance resources are in that region ...
According to this documentation, each vault has to be unsealed in a HA setup.
Now you need to initializing and unsealing each Vault instance.
# Initialize vault_s1
$ vault operator init
# Unseal the vault_s1
$ vault operator unseal <unseal_key_1>
$ vault operator unseal <unseal_key_2>
$ vault operator unseal <unseal_key_3>
Well, the first step is to use a backend which supports HA. Consul, for example, supports HA. If you are not an enterprise customer, you may have to run a shell script via cron to upload consul snapshots to s3 or where ever you want to store them. Later, you can restore all your secrets. And obviously, the snapshots are encrypted.