Облако давно воспринимается как нечто безграничное - ресурсов там как будто всегда достаточно, сколько бы клиентов ни подключилось. На деле за этим стоит вполне конкретное оборудование, которое просто грамотно распределяется между множеством клиентов одновременно. Мы поговорили с Нурсултаном Нуртазаулы, архитектором в области облачной инфраструктуры о том, как устроена эта механика - мультиарендность, на чём держится изоляция между клиентами и что происходит, когда ресурсов начинает не хватать всем сразу.
Здравствуйте! Спасибо, что согласились поговорить на эту тему.
Нурсултан: Здравствуйте! Тема действительно интересная - про мультиарендность редко говорят простыми словами, хотя с ней так или иначе сталкивается любой, кто пользуется облаком.
Что такое мультиарендность и зачем она вообще нужна провайдеру?
Нурсултан: Мультиарендность (multi-tenancy) - это архитектурный принцип, при котором один и тот же физический кластер серверов, хранилища и сети одновременно обслуживает множество независимых клиентов - арендаторов, - при этом каждый из них видит только свои ресурсы и данные, как будто работает в изолированной среде.
Для провайдера это вопрос экономики: содержать отдельное железо под каждого клиента дорого и неэффективно, ведь редкий заказчик утилизирует выделенные мощности на сто процентов постоянно. Когда десятки клиентов делят один и тот же кластер, их пиковые нагрузки в среднем не совпадают по времени, и провайдер может обслуживать гораздо больше арендаторов на том же оборудовании, чем если бы резервировал ресурсы под каждого отдельно.
Как обеспечивается изоляция между клиентами, если они физически на одном железе?
Нурсултан: Изоляция строится на нескольких уровнях одновременно, и ни один из них не работает сам по себе.
На уровне вычислений - это гипервизор, который разделяет физический сервер на изолированные виртуальные машины: каждому клиенту выделяются виртуальные вычислительные ресурсы с заданными гарантиями и ограничениями, а планировщик гипервизора распределяет между ними реальные такты процессора. На уровне сети используются технологии логической сегментации, такие как VLAN и VXLAN, а также механизмы изоляции маршрутизации, например VRF, - вместе они гарантируют, что трафик одного арендатора логически не пересекается с трафиком другого, даже если физически идёт по общим коммутаторам. На уровне хранения - это разграничение через отдельные тома и квоты, а при необходимости данные дополнительно шифруются, в том числе с использованием отдельных ключей управления шифрованием, что дополнительно защищает данные одного арендатора от доступа со стороны другого.
Отдельный слой - управление доступом и идентификацией: у каждого арендатора свой набор учётных данных и ролей, и система должна гарантировать, что API-запрос одного клиента физически не может затронуть ресурсы другого, даже если в запросе есть ошибка или уязвимость на уровне приложения.
Что происходит, когда один клиент начинает потреблять слишком много ресурсов и мешает остальным?
Нурсултан: Это классическая проблема «шумного соседа» (noisy neighbor) - когда один арендатор из-за пиковой нагрузки начинает забирать себе непропорционально много общих ресурсов, и это сказывается на производительности у соседей по кластеру.
Решается это через квоты и лимиты: каждому клиенту выделяются гарантированные ресурсы и устанавливаются ограничения, определяющие, сколько ресурсов он может использовать, - конкретное поведение при этом зависит от политики облачной платформы. Дальше в дело вступают механизмы приоритезации трафика и вычислений (QoS) - система решает, чей запрос обслужить в первую очередь, если ресурсов на всех не хватает в момент. Наконец, провайдеры постоянно следят за общей загрузкой кластера и перераспределяют нагрузку между узлами так, чтобы дисбаланс не успевал стать заметным для клиента.
Насколько эта задача решена технически, или это до сих пор источник инцидентов?
Нурсултан: Технологии зрелые, но идеальной изоляции не существует - это скорее непрерывный процесс балансировки, чем разовая настройка. Даже при полностью корректной архитектуре случаются ситуации, когда неудачное совпадение пиковых нагрузок нескольких крупных арендаторов создаёт временную деградацию для остальных. Поэтому серьёзные провайдеры закладывают запас мощности заранее и держат кластер не полностью, а частично загруженным - именно ради таких неожиданных пиков.
Как клиенту вообще понять, что его данные и ресурсы действительно изолированы, если он этого не видит?
Нурсултан: Здесь работает та же логика разделения ответственности, что и в облаке в целом: провайдер отвечает за корректность архитектуры изоляции и обычно подтверждает это независимыми аудитами и сертификациями инфраструктуры. Клиент, как правило, не видит внутреннюю архитектуру напрямую, и это нормально: подтверждением служат независимые аудиты и отраслевые сертификации, а не собственная техническая проверка каждого клиента.
Спасибо большое за такой подробный разбор!
Нурсултан: Спасибо вам за вопросы - было приятно поговорить о теме, которая обычно остаётся за кадром для конечных пользователей облака. Если одной фразой: мультиарендность - это компромисс между экономикой и инженерией, и чем он незаметнее для клиента, тем качественнее он реализован.