4 ms·

Interesting offering, looks damn cool ^_^. There are a few interesting questions raised, though. Are you guys using local disks or SAN? Are you guys using Eu

by asharp 15y ago

Interesting offering, looks damn cool ^_^. There are a few interesting questions raised, though. Are you guys using local disks or SAN? Are you guys using Eucalyptus? Also, it's interesting that you charge less for incoming data then outgoing. I understand that standard asym links are cheaper upload then download, due to them being basically "slack" cap from Adsl tails/etc. Why is your outbound data more expensive then? How are you securing KVM? (assuming somebody from there is around, or that anybody else would have answers....)

jeremyjarvis 15y ago
> Are you guys using local disks or SAN? No SANs, anywhere! :) > Are you guys using Eucalyptus? It's our own stack. Eucalyptus afaik doesn't handle zones as geographically distinct datacentres and, when we looked at it a long time ago, had some pretty worrying SPOFs. > Why is your outbound data more expensive then? Transit is symmetrical, and incoming bandwidth is less utilised compared to outgoing so we charge less for it. > How are you securing KVM? In what sense? (Co-founder at Brightbox)
- asharp 15y ago
  > No Sans Ephemeral disks? Or persistent local? > Our own stack Very cool ^_^ How do you deal with geographic zones? Are they silod? > Bandwidth Ok, makes perfect sense. Thanks. > Securing KVM Do you use cfgroups/selinux to deal with compromise of a kvm domain? I've seen quite a few vulnerabilities coming out on the debian/etc. security mailing lists.
  - comice 15y ago
    > Ephemeral disks? Or persistent local? Persistent local disks (hardware raid6 15k rpm). More storage options on the roadmap too. > Very cool ^_^ How do you deal with geographic zones? Are they silod? Our zones are different datacenters in different buildings, with completely different power supplies, UPSes and backup generators. > Do you use cfgroups/selinux to deal with compromise of a kvm domain? cgroups currently, selinux in development. (full disclosure: I'm a Brightbox bod too!)
    - asharp 15y ago
      > persistent disks How do you then deal with people who create an instance and then don't run it. Unless i'm mistaken, you'd be forced to either unbalance for storage or VM usage. > cgroups currently How do you protect the kernel from something like CVE-2011-2212? Quite cool otherwise :)
      - rednaught 15y ago
        Not sure what distro he is using but Debian and RHEL have patches for this. http://security-tracker.debian.org/tracker/source-package/qemu-kvm http://security-tracker.debian.org/tracker/source-package/qe... http://security-tracker.debian.org/tracker/CVE-2011-2212 http://security-tracker.debian.org/tracker/CVE-2011-2212 https://rhn.redhat.com/errata/RHSA-2011-0919.html https://rhn.redhat.com/errata/RHSA-2011-0919.html
        asharp 15y ago
        I know of this. The interesting question it brings up is how do you keep a cloud like this patched and up to date without dropping SLA?
        rednaught 15y ago
        Patching is normally considered part of scheduled or emergency maintenance and therefore doesn't count against the SLA for uptime. This is fairly standard in the hosting/ISP world. So much of this can be automated now that it is not a problem. As a provider myself, I allow customers to pick their patch day/time. They can even manually push patches themselves and be present to test when the service comes back up. Proactive maintenance(datacenter, networking, hardware, OS, and appptack/utils) should be considered a way of life these days if you're a provider. If customers don't understand or agree with that, then there are plenty of providers who don't keep up-to-date offerings that they can migrate to.
      - comice 15y ago
        You start paying for an instance as soon as you create it, whether you're running it or not. To keep a disk image around for an instance without paying for the instance, you can use snapshots, which use a different storage system. We protect against those types of problems at the moment with keeping patched up to date. Xen doesn't solve this problem either, it has had it's own share of vulnerabilities with these kinds of repercussions. Even selinux only mitigates some of the risks - not all. A combination of mandatory access control and a good update, audit and monitoring strategy is the best approach imo.

by asharp 15y ago

jeremyjarvis 15y ago

> Are you guys using local disks or SAN? No SANs, anywhere! :) > Are you guys using Eucalyptus? It's our own stack. Eucalyptus afaik doesn't handle zones as geographically distinct datacentres and, when we looked at it a long time ago, had some pretty worrying SPOFs. > Why is your outbound data more expensive then? Transit is symmetrical, and incoming bandwidth is less utilised compared to outgoing so we charge less for it. > How are you securing KVM? In what sense? (Co-founder at Brightbox)

asharp 15y ago
> No Sans Ephemeral disks? Or persistent local? > Our own stack Very cool ^_^ How do you deal with geographic zones? Are they silod? > Bandwidth Ok, makes perfect sense. Thanks. > Securing KVM Do you use cfgroups/selinux to deal with compromise of a kvm domain? I've seen quite a few vulnerabilities coming out on the debian/etc. security mailing lists.
- comice 15y ago
  > Ephemeral disks? Or persistent local? Persistent local disks (hardware raid6 15k rpm). More storage options on the roadmap too. > Very cool ^_^ How do you deal with geographic zones? Are they silod? Our zones are different datacenters in different buildings, with completely different power supplies, UPSes and backup generators. > Do you use cfgroups/selinux to deal with compromise of a kvm domain? cgroups currently, selinux in development. (full disclosure: I'm a Brightbox bod too!)
  - asharp 15y ago
    > persistent disks How do you then deal with people who create an instance and then don't run it. Unless i'm mistaken, you'd be forced to either unbalance for storage or VM usage. > cgroups currently How do you protect the kernel from something like CVE-2011-2212? Quite cool otherwise :)
    - rednaught 15y ago
      Not sure what distro he is using but Debian and RHEL have patches for this. http://security-tracker.debian.org/tracker/source-package/qemu-kvm http://security-tracker.debian.org/tracker/source-package/qe... http://security-tracker.debian.org/tracker/CVE-2011-2212 http://security-tracker.debian.org/tracker/CVE-2011-2212 https://rhn.redhat.com/errata/RHSA-2011-0919.html https://rhn.redhat.com/errata/RHSA-2011-0919.html
      - asharp 15y ago
        I know of this. The interesting question it brings up is how do you keep a cloud like this patched and up to date without dropping SLA?
        rednaught 15y ago
        Patching is normally considered part of scheduled or emergency maintenance and therefore doesn't count against the SLA for uptime. This is fairly standard in the hosting/ISP world. So much of this can be automated now that it is not a problem. As a provider myself, I allow customers to pick their patch day/time. They can even manually push patches themselves and be present to test when the service comes back up. Proactive maintenance(datacenter, networking, hardware, OS, and appptack/utils) should be considered a way of life these days if you're a provider. If customers don't understand or agree with that, then there are plenty of providers who don't keep up-to-date offerings that they can migrate to.
    - comice 15y ago
      You start paying for an instance as soon as you create it, whether you're running it or not. To keep a disk image around for an instance without paying for the instance, you can use snapshots, which use a different storage system. We protect against those types of problems at the moment with keeping patched up to date. Xen doesn't solve this problem either, it has had it's own share of vulnerabilities with these kinds of repercussions. Even selinux only mitigates some of the risks - not all. A combination of mandatory access control and a good update, audit and monitoring strategy is the best approach imo.