-
Notifications
You must be signed in to change notification settings - Fork 23
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Availability Zones: standardized levels of independecies. #539
Comments
Why are we talking about AZs: AZs focus on redundancy and failure safety on IaaS-Level. While redundancy at the lowest level could be just something like having replication in the storage backend, so there is no data loss in the case of a hardware failure, the requirements can be as hard as having a remote mirror of all data.
Pre-RequirementsTo also allow having small deployments or edge deployments, that usually only have 1 single AZ, we must not require a certain amount of AZs. We should rather define and check, for when AZs can be defined and used. What can AZs be defined of / What can they separate
AZs are logical separations with a chance of physical separation.
Problems:
Restrictions:
A good but a bit outdated overview was presented at the Summit in 2018 ( https://www.youtube.com/watch?v=a5332_Ew9JA ) Proposal:
|
I created a hedgedoc for CSPs to talk about their AZ usage: |
Up until now, there was not much input - so I put it on the agenda again for the next IaaS call |
A few CSPs answered the questions in the hedgedoc, so we can go on with the work on AZs. The problem here is, when in a deployment AZs are used differently those deployment might not be changed, because change the AZ-architecture is quite fundamental. So all other deployments would be automatically rendered scs-incompatible. Another option is to use the failsafe levels that will be defined in #527, this would be more vague - we should discuss, whether we want this or not. |
We should base our standard on the Taxonomy DR (#579) and start a requirement analysis from that levels. Additionally the answers from CSPs in the hedgedoc are quite helpful, as they already proposed some minimum setup for AZs:
We do have to also consider that AZs exit for Compute, Network and Storage independently. And some of them might be easily mitigated by configuration (storage) or are not easily manageable in openstack:
Requirements
Decisions
|
In todays IaaS call, we discussed a few open questions: Network AZIn the standard I discussed, that it is possible to have Network AZ, but this has downsides for users. Thus i did not make any recommendations. We discussed, whether we even want to discourage CSPs to use it ("SHOULD NOT"):
Cross-Attach AZQuestion was, whether we want to encourgage / allow / discourage or disallow this?
Overall
|
Availability Zones are a concept in OpenStack.
As a user of an scs-conformal cloud I want to know what i can expect from AZs overall and what is dependent on the CSP.
Definition of Done:
Please refer to scs-0001-v1 for details.
scs-xxxx-v1-slug.md
(only substituteslug
)status
,type
,track
setDraft
, file renamed:xxxx
replaced by document numberDraft
)The text was updated successfully, but these errors were encountered: