Skip to content
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

Network interface speed #96

Open
horazont opened this issue Jun 18, 2021 · 2 comments
Open

Network interface speed #96

horazont opened this issue Jun 18, 2021 · 2 comments

Comments

@horazont
Copy link
Member

See SovereignCloudStack/docs#98 for my definition of Prio 1-4.

  • Prio 3: As a Cloud Operator, I want to know when a network interface drops below the specified maximum speed on that link, as that indicates bad cabeling, a bad driver, or another (hardware) issue and may cause customer impact (reduced performance).
  • Prio 2: As a Cloud Operator, I want to know when the network interfaces of a compute node are saturated, as that causes degration of performance.
@garloff
Copy link
Contributor

garloff commented Jun 18, 2021

On the second piece:

  • Isn't it normal for a NIC to be saturated from time to time? Even if you do some bandwidth management (e.g. with Linux HTB traffic control), you still allow the full bandwidth to a single VM (if the others are silent) or to the VMs together. So I would expect saturated NICs to be rather normal for a highly utilized compute host.
  • There is typically nothing an operator could do short-term, except maybe live-migrating VMs to less busy hosts. This might be a possibility if such an event happens very seldomly. I still wonder whether you would want to be woken up during the night for this. And assuming my statement on this being a fairly frequent thing, we'd either have automated initiation of live migrations or ignore this. (We could however think about a prio 3 alarm if the workload management system does not find a good target host... If a live migration failed, we need to check whether the VM has survived. If not, this would be a prio 1 thing.)

@horazont
Copy link
Member Author

You’re right that Prio 3 or 4 may be much more fitting for that one.

@itrich itrich transferred this issue from another repository Aug 12, 2022
reqa added a commit to reqa/SovereignCloudStack-Docs that referenced this issue Sep 8, 2022
…reignCloudStack#160)

* Design-Docs/IAM-federation/keystone-keycloak-federation.md
  plus two sketches (SovereignCloudStack#96)

* ../Decisions/intra-SCS-federation-setup-description-for-osism-doc-operations.md
  as proposal for (SovereignCloudStack#160)

Signed-off-by: Arvid Requate <requate@univention.de>
fkr pushed a commit that referenced this issue Sep 13, 2022
…114)

* Design-Docs/IAM-federation/keystone-keycloak-federation-diagram. Source and PNG.
   (#96)

Signed-off-by: Juan Pedro Torres <torres-munoz.extern@univention.de>

Signed-off-by: Juan Pedro Torres <torres-munoz.extern@univention.de>
Co-authored-by: Juan Pedro Torres <torres-munoz.extern@univention.de>
fkr pushed a commit that referenced this issue Sep 13, 2022
* Design-Docs/IAM-federation/keystone-keycloak-federation.md
  plus two sketches (#96)

* ../Decisions/intra-SCS-federation-setup-description-for-osism-doc-operations.md
  as proposal for (#160)

Signed-off-by: Arvid Requate <requate@univention.de>

Signed-off-by: Arvid Requate <requate@univention.de>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants