Я никогда не встречал хостинговую компанию / облачную компанию, которая обеспечивала бы истинное вертикальное масштабирование без необходимости выключать компьютер и / или копировать веб-сайт или виртуальную машину на другой компьютер. Я видел только сервисы / информационные панели, которые говорят о вертикальном масштабировании, но на самом деле просто абстрагируются от процесса, описанного в моем предыдущем предложении.
В настоящее время невозможно добавить / удалить ОЗУ и ЦП без предварительного выключения машины? Или для хостинговых компаний просто недостаточно рентабельно предлагать это? (или я ошибаюсь и есть компании, которые обеспечивают вертикальное масштабирование на одной машине без простоев)?
Если это невозможно, то почему? Есть ли ограничение на то, на что способны текущие процессоры?
Возможно онлайн вертикальное масштабирование. Но аппаратное и программное обеспечение должно поддерживать это, и, возможно, что более важно, поставщик услуг должен быть заинтересован в предоставлении вам этой функции.
Например, IBM Power Systems объединяет несколько узлов в одну систему. Функции существуют для горячее добавление узла путем физической установки в стойку и подключения другого блока процессоров. Затем процессоры и память могут быть добавлены к работающим разделам (виртуальным машинам).
Такая ремонтопригодность стоит дорого, предприятия будут платить за нее доплату. Также относительно сложно.
В отличие от многих обычных облаков, обычно работающих под управлением x86. Размеры ваших экземпляров - это фиксированный список, и переключение на другой - это перезагрузка, но вы можете иметь их сколько угодно. Стоимость, как правило, ниже из-за менее продвинутых функций RAS и экономии на масштабе.
Эти облака предпочли бы, чтобы вы масштабировали вне к нескольким хостам. У них есть гораздо больше экземпляров того же размера, размещенных на оборудовании оптимальным образом. Горячее добавление было бы дорогостоящим только из-за перебалансировки нагрузки с виртуальными машинами разного размера. Зачем заниматься разработкой, если можно убедить архитекторов и разработчиков масштабироваться.
Это возможно в зависимости от платформы, но по-прежнему требует предварительного планирования емкости.
Во многих гипервизорных платформах существует понятие «раздува памяти». Это позволит вам указать «текущий» объем ОЗУ, а также «максимальный» объем ОЗУ. Максимум - это жесткое ограничение, которое определяется заранее, но механизм раздувания позволяет гостевой ОС, которая не полностью распределила свою карту максимальной памяти на гипервизоре, расширять то, что ей выделено, по запросу. Это в основном полезно в лабораторных средах и для статически развернутых рабочих нагрузок, от которых вы ожидаете больших и нечастых всплесков выделения (но не сразу при избыточном выделении ресурсов).
То же самое можно применить к ресурсам ЦП, указав «максимальное» количество ядер или процентное соотношение ядер и выделив их от «мягкого» значения до максимального «жесткого» значения.
Это уловка виртуализации, которую можно рассматривать как прямую параллель с аппаратными системами горячей замены. Мы делаем вид, что у виртуальной машины есть дополнительные незаполненные слоты памяти или незаполненные дополнительные процессоры. Но нам еще нужно точно определить количество слотов.
Обычно вы можете добавлять дисковое хранилище на лету практически к любому экземпляру на большинстве платформ, не беспокоясь ни о чем из этих проблем.
Однако системы облачной оркестрации, как правило, имеют хорошо реализованные и автоматизированные системы развертывания, что делает такие модели гораздо более бесполезными (за исключением добавления хранилища, что почти всегда так же полезно).
Учтите, что многие поставщики взимают плату за выделенную емкость, а не за используемую емкость. Реализация модели экземпляров с динамическим вертикальным масштабированием создает еще один уровень проблем планирования и распределения ресурсов для поставщиков - во-первых, любому количеству клиентов может потребоваться довольно много ресурсов одновременно, но также и то, что любой из этих клиентов может создавать эти экземпляры. вздутие живота в любое время.
Единственный способ правильно спланировать с точки зрения облачной инфраструктуры в этом случае - это выделить экземпляры в соответствии с их максимальной емкостью и правомерно взимать плату за это распределение, которое в противном случае они могли бы позволить другому клиенту.
Тогда почему бы просто не использовать максимум, если за это уже нужно платить? И если мы делаем что-то с максимальной мощностью, тогда снова становится необходимым переопределение экземпляров для выполнения вертикального масштабирования.