Комментарии 19
Аггрегейты/бэкбон-коммутаторы кто конфигурирует? А маршрутизатор с быгыпой?
Все хотят своими грязными мягкими (soft) ручками сеть DC потрогать и никому не дают, потому что если там будет TRACE unhandled exception, то ничего не будет. Ни отладки, ни логстеша, ни даже ремутного impi'ки.
Все хотят своими грязными мягкими (soft) ручками сеть DC потрогать и никому не дают, потому что если там будет TRACE unhandled exception, то ничего не будет. Ни отладки, ни логстеша, ни даже ремутного impi'ки.
На данном этапе есть только инфраструктура всофтсвича, планируем сделать образ для маркетплейса с квагой, преднастроенной для развёртывания BGP через нас, как iBGP — но это следующий этап — там достаточно серьёзные доработки. Защитой от левых ас будет прописывание клиентом в RIPE object-route. Мы это делаем, мы об этом знаем.
Это всё ковыряние в песочнице. по 10Гб на 48 портов вы так даже близко не прокачаете.
ЗЫ ovs какой версии?
ЗЫ ovs какой версии?
1.9.3
О, боже.
Я для кого писал? habrahabr.ru/company/webzilla/blog/124310/
А первый раз я про это написал ещё в начале прошлого года. Не следите за рассылками. Стыдно.
Я для кого писал? habrahabr.ru/company/webzilla/blog/124310/
А первый раз я про это написал ещё в начале прошлого года. Не следите за рассылками. Стыдно.
Ээх, вот были хорошие шведы Tail-F для этих целей, но Кискам очень захотелось их прибрать к рукам :(
Больше интересно как будут обработаны нестандартные ситуации на оборудовании, грубо говоря подвис IPMI или, например, на этапе установки системы словили ошибку памяти или еще что, не будет ли так что клиент включил установку и через 2 часа начинает задалбывать ТП так как ничего не происходит, тогда уж лучше дать клиенту IPMI и доступ к хранилищу образов а не вебинтерфейс. Про ovs уже сказали выше.
Немного забегая вперёд, скажу, что мы активно работаем над вопросом миграции образа виртуальной машины на физический сервер, что, на мой взгляд очень востребовано стартапами, которые выходят на хороший продакшн.
Что-то сложнее этого?
На компьютере с чистым размеченным жестким диском запускаем live CD, открываем терминал и задаем команду:
nc -l 10000 > /dev/sda
На компьютере с установленным и настроенным дистрибутивом или виртуалкой тоже запускаем live CD и в терминале печатаем:
nc 192.168.1.2 10000 < /dev/sda
Если диски разные по размеру после переноса делаем resize2fs
nc -l 10000 > /dev/sda
На компьютере с установленным и настроенным дистрибутивом или виртуалкой тоже запускаем live CD и в терминале печатаем:
nc 192.168.1.2 10000 < /dev/sda
Если диски разные по размеру после переноса делаем resize2fs
Откуда взялся термин что-то as a service? От нежелания или невозможности создать инфраструктуру с нуля самому. Это некий набор сценариев, доступных через веб-морду. Конечно шельная реализация работает, но только для нас, им надо дать простой и рабочий интерфейс.
Т.к. вы говорите про голое железо, то кроме маркетингового описания хочется увидеть как решены варианты обработки не стандартных ситуаций, которых на голом железе просто огромное количество, если не готовую реализацию то хоть идею, указанные вами технологии даже близко не решают эту задачу, я дал вам простой кейс, временный не критичный отказ одного из компонентов сервера и как поведет себя система в этом случае? Ну банально при разворачивании образа произошел сбой в передаче данных, как будет обработана ситуация? Вы же вместо ответа задаете риторический вопрос, по поводу миграции мой вопрос вообще оставили без ответа. Все-таки на хабое хочется видеть не только грубый пиар своей компании но и технические моменты реализации, в вашем топике я лично их не вижу, надеялся уточнить, но видимо в ваши задачи не входят ответы на такие вопросы.
Это не пиар. Отказ IPMI я ни разу не встречал, поэтому при проектировании мы даже и не думали об этом. Кейс имеет место быть — но его нужно воспроизвести. На самом деле доклад будет совсем не такой, как он описан — я расскажу даже как из среды DCaaS аннонсировать свою AS — он будет не маркетингом — чистый дев.
Проект совсем молодой — 3.5 месяца — ессно нам пока немного, что показать — но заложенный базис есть и он очень отличается от IaaS.
Проект совсем молодой — 3.5 месяца — ессно нам пока немного, что показать — но заложенный базис есть и он очень отличается от IaaS.
За крайний месяц встречал отказ IPMI трижды, в 2х случаях это DELL-овский idrac, в одном supermicro (да эту дрянь тоже ставят, ну можно его не считать) это на небольшую выборку около 500 физических серверов, несколько умерших батареек на BBU, развалившийся кашкад, не корректно отработавший ECC на одной из планок памяти в сервере из за не совсем корректной установки, развалившийся аппаратный рейд 10 из 64 дисков, который до этого нормально был собран, ошибка прошивки контроллера на инициализации. Исключений при автоматическом деплое ОС наберу штук 5, от сбоя передачи образа до не корректной обработки образом новой версии контроллера SAS, могу еще припомнить разного, на нескольких серверах этого не словить, но на большой выборке что-то «отваливается» регулярно, когда это не кластер виртуалок — среда несколько не однородна, включая разные версии фирмвар на идентичных серверах — это все нужно как-то обрабатывать и решать, вот и интересно как с этим справляется система, просто все остальное реализуется не очень сложно через API на IPMI. Анонс автономки для любого бордера достаточно легко скриптуется, там все стандартно, особенно на взрослых маршрутизаторах, с пользовательским железом намного интереснее, его больше и соответственно разных ситуаций и отказов намного больше.
При условии, что ноды выводятся и вводятся в течении 30-40 секунд, заменить процесс, который пользователь видит как просто полоску процесса — не проблема. Это не касается HP — там всё очень плохо с серии Gen8 — это мы опустим. Dell не используем — пришли к мнению, что для нас оптимально SuperMicro. Сервера на memtest тестируются до ввода в состояние ready-for-user-deploy. Райд на серверах не собирается — с условием CEPH — он просто не нужен. LiveMigration для образов с HA тоже не требует особенного внимания. Главное в структуре не падать на размазывание данных с коэффициентом 2 — минимум 3-4. Боевые снапы и зеркало хранения на EMC2 хранилище — это 4 по 40 гигабит линки с бондингом по коммутации.
Аннонс с автономки нельзя скриптовать в структуре услуги… это должно быть прозрачно для клиента. Приходите на девконф, расскажу.
Аннонс с автономки нельзя скриптовать в структуре услуги… это должно быть прозрачно для клиента. Приходите на девконф, расскажу.
Тогда в вашем случае это фактически виртуализация или облако, но не «голый» физический сервер. С виртуалками все предсказуемо, полки под диски отдельно, гиперы отдельно, живая миграция, потеря любого из узлов не критична, меня заинтересовал именно выдача «голого» железа клиенту причем в разновендорной сети, т.к. далеко не все готовы держать проекты на supermicro (нижний ценовой сегмент, качество откровенное SOHO). CEPH — отличный инструмент для размазывания нагрузки, но к сожалению не подходит для проектов с высокими требованиями к io, ну и если клиенту нужен одиночный сервер заданной конфигурации, не всем подходят облака.
Так «голое» и есть — просто логистика действия клиента сильно изменена — суть именно в том, что клиент не получает в точке входа кабинет виртуальной инфраструктуры. Точка входа — просто список доступного физического оборудования с которым клиент может работать в любых доступных направлениях — собрать свой мини-Амазон, просто установить ОС на физику… все остальные опции — бекапа, связанности — это то, что поставляется не поверх, не внизу — а в стороне — что бекап физической машины, что набора виртуалок, собранной инфраструктуры. И самое главное — это не нужно волноваться за перерасход ресурсов. Есть чёткая, прозрачная фиксированная тарификация.
Выглядит очень похоже решение-аналог cisco UCS.
dcaas.ru/ говорит «Ошибка установки соединения с базой данных» — так и должно быть?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
DCaaS — новая модель сервисов