Bringing Browser-Based MFA SSO to the OpenStack CLI
Learn how a lightweight keystoneauth1 plugin brings your existing browser-based MFA and SSO to the OpenStack CLI, with no changes to any client tools.
Perspectives, mises à jour et histoires de notre équipe
Learn how a lightweight keystoneauth1 plugin brings your existing browser-based MFA and SSO to the OpenStack CLI, with no changes to any client tools.
Hyperscaler AI looks fast but hides long-term lock-in and rising costs. See how OpenStack and Kubernetes deliver GPU infrastructure you actually control.
Many AI clusters run at only 30–50% GPU utilization. Learn why GPUs sit idle and how Kubernetes, scheduling, and better infrastructure design can improve AI infrastructure efficiency.
Disaster recovery should never be taken lightly, especially where cloud computing is concerned. Check out some of the key mistakes that are made and ensure your organization is properly prepared!
With disaster recovery playing such an important role in the security of your cloud, it's vital to be aware of some of the areas where your organization might be unknowingly at risk. Three of the most common and critical mistakes made involve mixing up disaster recovery, high availability and fault tolerance, thinking that your infrastructure is immune to failure and confusing disaster recovery with continuity of operations planning.

Although disaster recovery, high availability and fault tolerance may seem like they refer to the same concept and solve the same issues, this isn't actually the case. High availability, for example, is designed to address service interruptions whereas disaster recovery aims to address major disasters. This means that regardless of having a core router with high availability and even fault tolerance, your network is still vulnerable to a disaster.
Under those circumstances, while your application remains unaffected in the cloud, the connection that your organization has to it has been severed and requires the restoration of IT system access that is normally provided for by your disaster recovery plan.

It's to be expected that most organizations focus on designing a system that doesn't fail, however, they sometimes then infer that a disaster recovery plan is no longer needed. Unfortunately, an all too well-known fact is that ignoring something doesn't make it go away, it simply leaves us unprepared.
In order to be adequately prepared, the possibility of failures can't be denied. Instead, they need to be planned for and mitigated throughout each phase of the design process - automatically or manually depending on where automation is possible.
Another critical mistake made by organizations is assuming that disaster recovery and continuity of operations planning are interchangeable. As with DR, HA and FT discussed in our first point, each planning aspect has it's own specific purpose that it serves.
While disaster recovery is heavily IT-focused, continuity of operations planning encompasses many facets such as processes, people and all other business essentials. These two plans also differ in terms of when they are brought into effect. A disaster recovery plan is implemented prior to a major event, and a continuity of operations plan dictates how to operate during a major event.
Disaster recovery planning will continue to play an important role in cloud computing and should not be regarded as an interchangeable aspect of securing your infrastructure. Companies desiring to safeguard against failure should include DR along with HA, FT and COOP.
Choose from Atmosphere Cloud, Hosted, or On-Premise.
Simplify your cloud operations with our intuitive dashboard.
Run it yourself, tap our expert support, or opt for full remote operations.
Leverage Terraform, Ansible or APIs directly powered by OpenStack & Kubernetes