Comments 9
Работаю сисадмином в небольшой компании, обслуживаю небольшую ферму виртуальных серверов. В собственном облаке вариант №5 возможно избыточен. А вот если рассматривать возможность перевода серверов из собственной серверной на сторонний хостинг (как это сделал ROLF), то этот вариант может быть очень даже приемлемым. Особенно ценным будет возможность сохранения схемы назначения адресов в процессе переноса, т.к. позволит минимизировать простои.
А эта система не поддерживает множественные таблицы маршрутизации?
Что вам мешает поднять на роутере провайдера в 4 схеме несколько VRF и пусть разные клиенты используют одинаковые адреса сколько им будет угодно? Фактически реализуется та же схема 5, но с меньшим количеством оборудования.
Что вам мешает поднять на роутере провайдера в 4 схеме несколько VRF и пусть разные клиенты используют одинаковые адреса сколько им будет угодно? Фактически реализуется та же схема 5, но с меньшим количеством оборудования.
Только схема 5 представляет собой публичное облако.
Остальные 4 схемы — частные облака. Насколько я понимаю, вы продаете i-oblako — т.е. свое публичное облако — там реализована 5я схема?
И есть еще вопрос по 4й схеме — почему вы решили, что " Большинство известных мне облаков построены именно на такой схеме." и не могли бы вы привести примеры?
Остальные 4 схемы — частные облака. Насколько я понимаю, вы продаете i-oblako — т.е. свое публичное облако — там реализована 5я схема?
И есть еще вопрос по 4й схеме — почему вы решили, что " Большинство известных мне облаков построены именно на такой схеме." и не могли бы вы привести примеры?
Публичное облако отличается от частного только контингентом пользователей. Если это сотрудники одной компании — это частное облако. Если кто угодно — публичное. Определения здесь. Поэтому сетевая инфраструктура любого облака может быть построена по любому из 5 вариантов.
Варианты 4 и 5 имеют защиту сетевого трафика от соседей, поэтому подходят для публичного облака в силу менталитета пользователей, которые заботятся о защите своего трафика. Публичное облако с сетью по 1,2 или 3 варианту не будут привлекательны на рынке, но так же будут публичными облаками.
Далее о терминологии: i-oblako — это витрина SaaS сервисов. Там есть один IaaS сервисI-Teco OpenStack Cloud, который мы и обсуждаем. Т.е. i-oblako — это не публичное облако.
Теперь о технике: I-Teco OpenStack Cloud это общее название. Там есть среда построеная на 4 варианте и среда, построенная на 5 варианте, но вариант реализации возможности выбора пользователем произвольной сети и IP адреса не реализован. Сейчас пользователю назначается внутренний адрес, который выбирается по умолчанию.
Мой вопрос как раз и был в том, чтобы определить — а нужна ли админам, которые потом будут работать с этим облаком, возможность самому назначать внутренние IP адреса своей инфраструктуры, или ценность этой возможности факультативна.
Примеры, о которых могу говорить — Гарант, Scalaxy, Rackspace и др. В них нет возможности задать требуемый пользователю IP адрес на ВМ. (ну или я о такой возможности не знаю) На Амазоне такая возможность есть в виде создания собственной частной сети.
Варианты 4 и 5 имеют защиту сетевого трафика от соседей, поэтому подходят для публичного облака в силу менталитета пользователей, которые заботятся о защите своего трафика. Публичное облако с сетью по 1,2 или 3 варианту не будут привлекательны на рынке, но так же будут публичными облаками.
Далее о терминологии: i-oblako — это витрина SaaS сервисов. Там есть один IaaS сервисI-Teco OpenStack Cloud, который мы и обсуждаем. Т.е. i-oblako — это не публичное облако.
Теперь о технике: I-Teco OpenStack Cloud это общее название. Там есть среда построеная на 4 варианте и среда, построенная на 5 варианте, но вариант реализации возможности выбора пользователем произвольной сети и IP адреса не реализован. Сейчас пользователю назначается внутренний адрес, который выбирается по умолчанию.
Мой вопрос как раз и был в том, чтобы определить — а нужна ли админам, которые потом будут работать с этим облаком, возможность самому назначать внутренние IP адреса своей инфраструктуры, или ценность этой возможности факультативна.
Примеры, о которых могу говорить — Гарант, Scalaxy, Rackspace и др. В них нет возможности задать требуемый пользователю IP адрес на ВМ. (ну или я о такой возможности не знаю) На Амазоне такая возможность есть в виде создания собственной частной сети.
Все приведенные схемы имеют проблемы при реализации в больших масштабах, 5 — наиболее простая для преодоления базового набора косяков, и при высокой сегментации машин клиента (в разных L3) сегментах, без использования туннелей она тоже работать перестанет.
Склонен с вами полностью согласиться в оценке проблем масштабирования.
Мне самому импонирует 5-я схема ровно потому, что через несколько лет и сотнях тысяч пользователей у меня останется свобода маневра. Однако сейчас вопрос в другом — давать или не давать пользователю возможность самому назначать произвольные сети и IP адреса для своей инфраструктуры в облаке. Это дополнительная фича, но и дополнительные затраты.
На ваш взгляд — такая доп. услуга была бы востребована?
А если эта фича будет платной?
Мне самому импонирует 5-я схема ровно потому, что через несколько лет и сотнях тысяч пользователей у меня останется свобода маневра. Однако сейчас вопрос в другом — давать или не давать пользователю возможность самому назначать произвольные сети и IP адреса для своей инфраструктуры в облаке. Это дополнительная фича, но и дополнительные затраты.
На ваш взгляд — такая доп. услуга была бы востребована?
А если эта фича будет платной?
Что подразумевается под произвольными сетями? У пользователя должен быть общий для всех его машин L2 сегмент, даже в случае географического разделения, а сеть «облака» должна уметь эти объединения строить без лишнего оверхеда. Можно взять более простые случаи, когда на уровне стойки заканчивается масштабирование всех сегментов второго уровня и в соседнюю уже требуется роутить — строить такое на любом классическом IGP провально из-за объемов правил. Ну и естественно, это должно быть бесплатно.
Естественно, облако умеет строить пользователю L2 сегмент поверх своей реальной географически распределенной сети и разнесенных ресурсов.
Пользователь в рамках своего L2, которая будет использоваться как внутренняя сеть, может настроить любую сеть: 192.168.0.0, 10.0.0.0, она принципиально может быть даже реальной сетью, на которой сервера стояли раньше. А на выходе будет натится в реальные IP.
А вот по поводу бесплатно — не уверен. Доп. железо, доп. ресурсы, доп. разработка.
Даже амазон фичу частных сетей бесплатно не делает :) Но, однако, деньги это не тема текущего топика.
Спасибо за ответ, я понял, что вам эта фича интересна.
Пользователь в рамках своего L2, которая будет использоваться как внутренняя сеть, может настроить любую сеть: 192.168.0.0, 10.0.0.0, она принципиально может быть даже реальной сетью, на которой сервера стояли раньше. А на выходе будет натится в реальные IP.
А вот по поводу бесплатно — не уверен. Доп. железо, доп. ресурсы, доп. разработка.
Даже амазон фичу частных сетей бесплатно не делает :) Но, однако, деньги это не тема текущего топика.
Спасибо за ответ, я понял, что вам эта фича интересна.
Sign up to leave a comment.
I-Teco OpenStack Cloud: Проектирование сетевой части OpenStack