Комментарии 25
MS Only, как я понял? Почему?
В основе нашей системы управления и мониторинга Parking Cube лежит глубокая интеграция с продуктами MS System Center, в качестве ОС для вашего проекта любая может быть любой. Мы просто традиционно работаем на продуктах Майкрософт и использовать что то другое (или выпиливать на коленке, например для XEN) для управления кластерами экономически не выгодно.
Vendor lock-in — не лучшая стратегия в долгосрочной перспективе. Но в краткосрочной можно хорошо подняться, да.
НЛО прилетело и опубликовало эту надпись здесь
Гигабита мало для репликации. Гигабит даёт только 100мег/сек, а нормальный диск даёт 150 мег/сек.
Рейд еще сильнее вызывает разброс.
Рейд еще сильнее вызывает разброс.
Схема условная, для каждого клиента каналы и прочее оговариваются отдельно.
Нормальный диск дает столько, сколько с него берет клиент. Если клиенту больше не нужно, то то, сколько диск «дает» в теории, для практики не слишком важно.
Да то понятно что «всего» около 100 мег/сек. Но это же трафик репликации — вы правда видели много проектов, у которых идет непрерывная запись порядка 100 мегабайт в секунду? Мне кажется это уже масштабы совсем другого уровня, тут обычно не cloud-hosting, а свой датацентр. Позвольте приведу примеры из реальной жизни — Exchange 2010 на грубо 10К активно используемых ящиков — в «часы пик» бывает трафик репликации доходит до 10-15 мб/сек. Нагруженная база SQL с документооборотом на примерно такую же толпу — бывает что тоже до 5-10 мб прыгает.
Но, во-первых, вы такие вещи все равно вряд ли будете виртуализировать (хотя Exchange из примера как раз виртуализован, но там 32 Гб памяти на машину, кажется у parking.ru такого нету). Ну и во-вторых — репликация не подразумевает совсем уж риал-тайм. Да, скинули мы на диск резко гигабайт 10 новых данных (опять же, не могу представить что за сервис) — ну ладно, появятся они на другой площадке через пару-тройку минут, не страшно.
Ну а если у вас новые данные пишутся постоянно — я тут посчитал вот, на скорости 100 Мб/с получаем 8 с копейками терабайт в сутки — тут явно нужен свой датацентр уже. А если все же не пишутся новые, а постоянно изменяются в реальном времени — опять же, не могу придумать в каких приложениях такое возникает.
Так что ваш наезд на скорость между площадками мне кажется абсолютно необоснованным. Думаю для 95% хостящихся проектов хватит вообще 10 Мбит, для оставшихся 5% — что-то среднее между 10 и 100.
Но, во-первых, вы такие вещи все равно вряд ли будете виртуализировать (хотя Exchange из примера как раз виртуализован, но там 32 Гб памяти на машину, кажется у parking.ru такого нету). Ну и во-вторых — репликация не подразумевает совсем уж риал-тайм. Да, скинули мы на диск резко гигабайт 10 новых данных (опять же, не могу представить что за сервис) — ну ладно, появятся они на другой площадке через пару-тройку минут, не страшно.
Ну а если у вас новые данные пишутся постоянно — я тут посчитал вот, на скорости 100 Мб/с получаем 8 с копейками терабайт в сутки — тут явно нужен свой датацентр уже. А если все же не пишутся новые, а постоянно изменяются в реальном времени — опять же, не могу придумать в каких приложениях такое возникает.
Так что ваш наезд на скорость между площадками мне кажется абсолютно необоснованным. Думаю для 95% хостящихся проектов хватит вообще 10 Мбит, для оставшихся 5% — что-то среднее между 10 и 100.
Думаю, что человек просто «теоретик» ;)
На практике у меня тоже висит один шланг для репликации. Но тут речь же идёт о высоконагруженном проекте?
«Шланг» как вы его назвали, не один :) Их как минимум два, так как каналы независимые и дублированные.
Так стоп, репликация идёт по одному гигабиту, или по двум? :)
В данной схеме идет полное дублирование всех каналов. Собственно два независимых гигабитных (можно больше, если есть необходимость) канала между дата-центрами, плюс по два независимых канала интернета из каждого дата-центра.
Они собраны в один двугигабитный транк, или это просто горячий резерв?
Это нужно уточнять, если не ошибаюсь то собраны в транк.
Уточнил, горячий резерв, для обеспечения надежности репликации данных.
Есть возможность плавно наращивать емкость по этим каналам репликации от 1 до 10 Гбит.
Есть возможность плавно наращивать емкость по этим каналам репликации от 1 до 10 Гбит.
А если не секрет — почему? У вас стоимость резервного канала константа, или по использованию?
У меня стоимость второго канала просто не окупается проектом, поэтому ограничиваюсь одним + vlan через public inet порт как резерв, и PI порт как раз по использованию тарифицируется — потому как резерв на случай факапа.
У вас, как понимаю, нормальная арендованная пара каналов, не вижу смысла не использовать простаивающие мощности.
У меня стоимость второго канала просто не окупается проектом, поэтому ограничиваюсь одним + vlan через public inet порт как резерв, и PI порт как раз по использованию тарифицируется — потому как резерв на случай факапа.
У вас, как понимаю, нормальная арендованная пара каналов, не вижу смысла не использовать простаивающие мощности.
Если использовать простаивающий резервный канал, и забить и его тоже, то когда отвалится один другого не хватит чтобы весь трафик прокачать. Гонять в случае чего через public — крайний случай, там RTD сильно больше да и девиация этого RTD непредсказуема, да и «на лету» в момент аварии схему быстро не перестроишь. Поэтому надо либо сразу закладываться одну физику + PI, либо на две физики. Не секрет, что стоимость аренды физики варьируется в зависимости от кучи условий, и иногда это совсем не дорого (это же не аплинки с интернет-трафиком).
Кстати, в схеме выше еще и не указано (из скромности наверное ;-) что в каждом из этих двух ЦОДов еще и аплинки резервированы. Один основной, один резервный (потоньше).
Кстати, в схеме выше еще и не указано (из скромности наверное ;-) что в каждом из этих двух ЦОДов еще и аплинки резервированы. Один основной, один резервный (потоньше).
Не знаю как в случае с MS продуктами, на DRBD в случае факапа одного канала понижается скорость репликации, и просто запись на диск становится медленней.
В таких условиях переключение на более тонкий даже канал репликации вызывает тормоза, но не падение — а это уже допустимо для ситуации аварии.
Внешний же канал обычно резервный ощутимо тоньше — и это считается нормальным, держать 100%й резерв основного канала таки дорого; еще один момент почему лучше держать два канала по 50% и в нормальной ситуации использовать оба — в случае факапа канал урезается в два раза, но в обычном состоянии нет простаивающих мощностей.
А эти два ЦОДа разнесены далеко? Узел связи стоит на разных IXах у каждого цода?
В таких условиях переключение на более тонкий даже канал репликации вызывает тормоза, но не падение — а это уже допустимо для ситуации аварии.
Внешний же канал обычно резервный ощутимо тоньше — и это считается нормальным, держать 100%й резерв основного канала таки дорого; еще один момент почему лучше держать два канала по 50% и в нормальной ситуации использовать оба — в случае факапа канал урезается в два раза, но в обычном состоянии нет простаивающих мощностей.
А эти два ЦОДа разнесены далеко? Узел связи стоит на разных IXах у каждого цода?
Как писали на баше — сливная труба в туалете она такая большая не потому, что траффик большой. А чтобы пиковые нагрузки пропускать.
А почему вы называете ваш кластер Геокластером, если на картинке изображены основной и резервный ЦОД с двумя разными кластерами?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Кластерные системы