21 lines
1.7 KiB
Plaintext
21 lines
1.7 KiB
Plaintext
{
|
|
"comments": [
|
|
{
|
|
"key": {
|
|
"uuid": "3acd31a7_b1e0c0fb",
|
|
"filename": "usecases/Virtual_IMS_Core.rst",
|
|
"patchSetId": 1
|
|
},
|
|
"lineNbr": 69,
|
|
"author": {
|
|
"id": 10707
|
|
},
|
|
"writtenOn": "2015-05-01T16:55:03Z",
|
|
"side": 1,
|
|
"message": "This is insufficient, as networking and storage must also not cause common host failures serving a single host. There are a couple of ways a cloud could implement this. When a cloud is implemented with non-redundant network connectivity, all of the hosts connected to the same switch(es) is in the same failure group. This applies to both switch serving VM/VM communication, and storage network (when present). Alternatively, at additional expense, the cloud can be built with redundant networking so that a single network component will not cause host failures. Similar constraints apply to storage. For example, if a single Ceph backend is used, it must be highly available. If one Ceph instance cannot be made highly available, multiple Ceph instances are needed, and the Ceph pool is the failure group.\n\nDepending on which models are selected, it affects what OpenStack capabilities are needed. Redundant network and storage do not require OpenStack code to be changed, but does change how it will be deployed, and may affect installers to configure the relevant redundancies in network and storage. Non-redundant network and storage requires OpenStack scheduling to understand the single points of failure when applying anti-affinity policies.",
|
|
"revId": "3da14300c448eac573e4e584edf9869ac36cf725",
|
|
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543",
|
|
"unresolved": false
|
|
}
|
|
]
|
|
} |