Недостатки облачных вычислений
- Существенная зависимость сохранности пользовательских данных от компании провайдера.
- Высокое качество услуг может быть обеспечено только при быстром доступе в сеть Интернет (недостаток, актуальный для российских пользователей).
- Проблема обеспечения безопасности при хранении и обработке важных пользовательских данных.
- Не каждое приложение позволяет сохранить на компьютере пользователя промежуточные и конечные результаты обработки информации. Онлайновые результаты удобны не всегда.
- Существует риск потери данных в результате крушения сервера провайдера онлайновых сервисов.
- Потеря полного контроля над данными, находящимися в он- лайн-сервисах.
Риски модели вычислений в облаке
- Мобильность данных. Большинство поставщиков услуг в облаке позволяют клиентам загружать и хранить данные, но при использовании чужих приложений приходится мириться с тем, что вы не можете получать все свои данные тем способом, к которому привыкли.
- Конфиденциальность. Большинство контрактов с поставщиками услуг в облаке содержат пункты, гарантирующие безопасность и конфиденциальность клиентских данных. Но, поскольку программное обеспечение мониторинга и управления для облаков находится в зачаточном состоянии, возможности клиентов узнать, кто и какие данные просматривает (особенно внутри их собственной организации), весьма ограниченны.
- Уровни безопасности. В облаках не принято всех мерить одной меркой. Приложения и услуги, получаемые каждым клиентом, подвергаются настройке. Но возможности адаптации к конкретным требованиям безопасности тут гораздо уже, чем во внутренних ЦОД, где /Г-технологии полностью подчинены реализации бизнес- целей компании.
- Интероперабельность. Настраиваемые внутренние приложения, используемые многими клиентами, зачастую несовместимы с общей инфраструктурой облака. Впрочем, многих это устраивает, поскольку вне зоны действия своих сетевых экранов компании согласны использовать лишь приложения весьма общего характера.
=================================================
Мой ответ - Важно понимать,что получая Вашу задачу Кластер Контроллеров (3 не менее) находит наименее загруженый Compute Node там, как правило, стартуется локальная для Compute Node Виртуальная машина (обычно это будет KVM гость, выполняющий скрипт cloud-init , то есть qemu-kvm процесс выполняющий Ваши задачи в некритическом фазе,вход в нулевое кольцо защиты qemu-kvm процесс совершает только в критической фазе для Вас это обычный ввод/вывод). Скорость определяется мощностью Compute Node и числом конкурирующих Виртуальных гостей на этом сервере (функциональность сервера в облаке есть Compute Node).
С большой вероятностью купив Собственный Сервер средней мощности и выполняя задачу на железе Вы получите результаты расчетов гораздо быстрее чем Вам их вернет облако Провайдера.
================================================
И тем не менее нужно понимать , что профессиональное Openstack Cloud толерантно к крушению сервера в любом из его кластеров вплоть до HA Controllers Pacemaker/Corosync Cluster (HA - High Availability). Качество развертывания Openstack Cloud корпорациями как Mirantis,Redhat,IBM достаточно высоко и такого рода развертываний сделано вполне достаточно для наличия отработанной схемы disaster recovery.
================================================
KVM виртуализация по
KVM - это функция виртуализации в ядре Linux, которая позволяет такой программе, как qemu-kvm, безопасно выполнять гостевой код непосредственно на центральном процессоре. Это возможно только в том случае, если целевая архитектура поддерживается центральным процессором. Сегодня KVM доступен на процессорах x86, ARMv8, ppc, s390 и MIPS. Чтобы выполнить гостевой код с помощью KVM, процесс qemu-kvm открывает /dev/kvm и выдает KVM_RUN ioctl. Модуль ядра KVM использует расширения аппаратной виртуализации, имеющиеся в современных процессорах Intel и AMD, для непосредственного выполнения гостевого кода. Когда гость обращается к регистру аппаратного устройства, Linux Kernel KVM module останавливает гостевой ЦП и выполняет другие специальные операции после чего KVM возвращается обратно в qemu-kvm. В этот момент qemu-kvm может эмулировать желаемый результат операции или просто ждать следующего гостевого прерывания в случае остановленного гостевого процессa.
Базовый поток гостевого ЦП выглядит следующим образом:
оpen ("/ dev / kvm")
ioctl (KVM_CREATE_VM)
ioctl (KVM_CREATE_VCPU)
for (;;) {
ioctl (KVM_RUN)
switch (exit_reason) {
case KVM_EXIT_IO: / * ... * /
case KVM_EXIT_HLT: / * ... * /
}
}
Upstream QEMU и Upstream QEMU-KVM слились в районе 2011 года. После примерно 5 лет работы над Upstream QEMU-KVM ( Redhat Supervision после поглощения Qumranet - собственно самостоятельно начавщей работать над QEMU-KVM. Тop Maintainer не менялся после слияния с RH )