ceph уже можно использовать! Я еще добавлю про openvz ploop, мы используем обе технологии. Мы тестировали онлайн миграцию и самописный автобалансировщик. Стабильно, но пока медленно. Пока только KVM можно положить на ceph storage, но, чисто теоретически, ничего не мешает сделать тоже самое с контейнером openvz-ploop.
ceph стабильный вроде как, ploop тоже. Для плуп надо лишь пересобрать vzctl, в pve собрали его с ключом --without-ploop.
Можно на ноды со сфинксом тоже повесить чеф и обмениваться сигналами через огайо. Тут тогда проблема все это синхронизировать. Чеф если висит демоном, и раз в полчаса сервер ему выдает команды, то есть шанс прождать час другой, пока все обменяется сигналами и продолжит деплой. Если запускать вручную, то будет быстрее. Но надо руками тогда заходить и запускать. Если нод болше чем 4, тут долго тоже )))
Тут мы поставим рандек и сами нажмем кнопку, когда нам надо синхронизируем.
Индексы сфинкса, например. Или еще какого движка. Версионность и совместимость можно обеспечить, но это сложно довольно. Синхронность кода, этих самых индексов и базы данных очень нужна, иначе мы покажем пользователю не то, что он запрашивал.
Rundeck это как Jenkins, но совсем для системного администратора, в таком ключе их можно сравнить. Мы все забилдили, надо выкладывать же. С десяток нод, есть среди них нетипичные и чем-то отличаются.
Рано или поздно процесс выкладки кода вообще перестает быть томным и сделать git clone (git pull) уже недостаточно, надо как-то сконфигурировать фреймоворк, подтюнить пхпшечку, подчистить кэш, но не весь. Чеф поможет.
Но чеф не умеет принимать во внимание связность компонентов. Допустим, обновить код на ноде только после того, как переиндексировался сфинкс и новые индексы уже залилились по всем нодам.
Он скрипт сначала загружает в домашний каталог пользователя, из под которого ссшится, потом его из под него и выполняет. Соответственно все непривилегировано, с полными путями и с правильным sudoers.
Момент такой, непростой, тоже помучались )
Насчет переселения. Вся виртуализация, и облака не исключение, основана на оверкоммитах по ресурсам и на коэффициентах мультиплексирования. Математика виртуализации предполагает, что все виртуалки никогда не загружены до предела. В большинстве случаев так и бывает. В гигабитную сеть можно напихать пяток виртуалок с почти честным гигабитом. Как и с памятью. Баллуны всякие надуваются сдуваются, все хорошо. Одна беда, пока не придумали как с дисками то быть.
И пока мы вдруг не сталкиваемся с перегрузом и коэффициенты мультиплексирования перестают вдруг работать. Все тормозит и еле шевелится у всех. Тогда самую тяжелую виртуалку переселят на другую машину и все по новой.
Я вам уже сколько вопросов задал — вы мне погуглить предлагаете. Я вам даже условия задачи написал, одной из тривиальных, еще и сложные бывают. Реальные проблемы, с которыми встретились — надуманные вдруг стали.
Не везде дадут настроить тот же sysctl. Не везде дадут выбрать драйвера сетевой карты. Вот полно ограничений. Думаете в облаках какая-то другая виртуализация, чудесная и без проблем? Резиновая, не ломается, с моментальной миграцией, без колтрейсов ядра и вытекших виртуализованных девайсов ога.
В общем все понятно, еще один облачный теоретик.
Вы там, кстати, ниже евры посчитали. Это что, за трафик только? Давайте плюсанем остальные ресурсы, память там, цпу, диск IO и подберем еще коэффициент по пиковым нагрузкам.
CDN еще есть. Он, кстати, не весь трафик умеет жевать. Если его сложно классифицировать и кэшировать, то мс никаких не будет, если вообще возьмутся доставлять. Еще не забудьте приплатить за девяточки в SLA.
CDN акей. Какой? Ссылка есть на прайс лист? Или так, слово вспомнилось из статьи?
Мы сейчас точно про облака? Или про VDS\VPS?
Нет, я опираюсь на то, что половину всех действий мне просто не дадут сделать. Настройки не зависят? Да пусть даже не зависят. Облака — это те же самые виртуалки на хардварной ноде. Если я обнаглею и забью хардварную ноду по какой либо метрике, меня либо зашейпят, либо переселят. Это потеря производительности и простой в сервисе. За огромные бабки. За килобаксы. Даже не будем брать во внимание такой важный параметр, как скорость дисков.
Объективно вот вам задачка. Есть 18 миллионов файлов, общим объемом 25 гигабайт. Нагрузка по полосе трафика на них постоянно 60 мегабит, по пику до 90. Бизнес требует, чтобы время ответа сервиса, использующего эти файлы, не превышало 300мс, допустим. С аптаймом 99,99.
Давайте попробуем решить.
Для размещения нам подойдет ubuntu. Раздавать будет nginx. Файлы положим на диск, раскидаем по дереву, чтобы у файлухи не сорвало башню. Также форматнем ее правильно, чтобы не кончились inode и правильно примонтируем. Памяти нужно много, чтобы под завязку использовать кеш, 16 гигабайт вполне должно хватить. Быстрый рейд на SAS 15k, чтобы все быстро читалось, когда кеш кончится. Надо также решить проблему с сетевым стеком, чтобы нам его не убило соединениями в состоянии TIME_WAIT, например. Подкрутим sysctl. Время ответа мы вроде обеспечим. Для отказоустойчивости нам желательно 4 таких ноды, желательно географически распределенных, из разных концов России latency разная, из Владивостока в Москву точно сильно долго ходить.
Посоветуете облако? Сколько мне надо денег в месяц, чтобы уехать в амазон с этим сервисом?
Чтобы голословным не быть, вот у нас такое облако есть.
Хранилище «ультра». Скорость записи маловата мягко говоря? При этом даже такой вариант слегка недешевый.
Этот ваш коммент к чему? Просили объяснить, почему мы не пользуемся облаками, я объяснил. При чем тут наш проксмокс и огромный штат того же AWS?
Проксмокс, да, наш, как хотим так и вертим. Колтрейснулось ядро — починили. Мало мощности — добавили ноду. Смигрировали в другую по потребностям. Если наши задачи узко-специализированные, то никакой штат и опыт людей из черного ящика не помогут заточить ширпотреб, который для всех, под такие задачи. И никто кроме нас также не справится лучше.
Мне вообще нравятся минусующие, которые про облака все знают по маркетинговым статьям. Или за два доллара визиточку с 2 хитами в месяц хостили в амазоне.
По факту один только мой бекенд с php-fpm внутри, с агрессивным кэшированием, с общей нагрузкой 500rps не живет ни в одном облаке, мы их все почти перепробовали. И это максимальные планы за килобаксы. За вменяемые деньги нет ничего вообще. На секундочку, наши проекты — это в целом больше 10 миллионов уников в месяц, с пиками на начало месяца, когда надо 5 терабайт отдать за три дня.
Да и не приходится потом изливать негодование на хабре, когда тут некое пропиареное и облачное сутками лежит, а потом информацию уже не достать оттуда. Поищите, тут такого полно.
Коммерческие облака — выдумка маркетологов какая-то. По факту — глючно, дорого, нестабильно, заявленные функции не совсем такие, как заявляются, мрак по ресурсам.
Вы так говорите, как будто в армии только копают, маршируют и скребут взлетки в казарме пряжками от ремней.
А как же учебные части, военные институты и школы?)) В армии можно получить очень интересное и разностороннее образование, куда лучше, чем в некоторых наших ВУЗах. Правда очень специализированное и с трудом применимое где-то помимо армии.
Есть определенный порядок, уставные документы, детально описан порядок любых действий вообще. Что касается передачи закрытой информации — тем более. Все под учетом и на все есть инструкция. Ключи, блокноты, шифры, бланки, журналы.
Закрытое сообщение должно быть однозначным и зашифрованным вполне определенными средствами, гарантированной стойкости или временной. И если оно должно быть, значит оно таким и будет. Ответственность за неправильное\неподобающее использование шифров и закрытых средств связи всегда была и будет очень высока.
Во времена Второй мировой уже были придуманы стойкие и в тоже время простые в эксплуатации шифры, например, одноразовые блокноты Вернама. И ими пользовались вовсю. Как пользовались акронимами после 30х годов, например, я не слышал.
Предположить, что связист взял стандартный бланк для криптограмм, оформил его по инструкции, но при этом не взял шифровальный блокнот, вместо этого используя непонятные акронимы, можно, но как-то слишком притянуто. Такое может быть возможно, если надо было передать очень важную информацию, а запасы шифров уничтожены, например. Однако, голубиная почта — не очень надежно для очень важных сообщений. 10% сообщений просто терялось, как в случае с этим голубем. Сплошные нестыковки же.
В любом случае ничего мы гарантировать не можем и эта еще одна загадка так ей и останется ))))
Все шифры я не знаю, конечно же. Но знаю большинство, используемых военными во времена военных действий.
Слишком много нестыковок.
Да и так не шифровали никогда. Акронимы — это слишком неоднозначно. Когда высока неоднозначность — получается очень сложный ключ.
Что-то типа
— вот если буква К в начале слова и после гласной, то это know, а если hv и на дворе среда, то тогда это high velocity, но посмотрим сначала, если есть b в середине, то читать как have".
Кстати, смысла шифровать служебные глаголы, артикли и всякие служебные языковые конструкции, просто нет.
В итоге проще взять одноразовый блокнот. Ну и группки по пять букв как бэ намекают на нормальный фабричный шифр. Как и специальный фабричный бланк для шифрограмм.
Если случилось такое, что кому-то плохо, то zabbix-sender может уже и не отработать. Я к тому, что инструмент хороший, но лучше использовать комбинированные механизмы.
И, кстати, что плохого собрать вообще все скрипты в один пакет, как например делает ZTC и ставить все разом, одним пакетом. Скрипты лежат, кушать не просят, а неразберихи меньше.
У нас большая связность компонентов. Нужна синхронность и обмен данными о состоянии нод. chef по-другому немного работает, чем бы хотелось. Когда код будет готов к signal based архитектуре и ноды будут между собой общаться сами, например не активировать некоторые интерфейсы, если еще не засинкались обновленные индексы, которых прям много. И в Москву из Новосибирска скорость заливки всего этого медленнее. Нет гарантии, что чеф в Москве, допустим, запустится вовремя и не слишком рано. Или читать из старой таблицы, если новая еще не готова.
Сейчас надо либо писать сложные рецепты с обменом информацией через ohaio, либо каким-то образом дирижировать клиентами chef, чтобы они включались когда нужно и деплоили то, что нужно ) Если учесть, что ноды еще и не типовые из-за split тестирования, то довольно сложно разобраться что и где сейчас на бою. Рецепт вроде один, но json с аттрибутами уже не один. Иногда надо быстро что-нибудь отключить или передеплоить. А чефу не прикажешь же. Он висит и ждет. Либо его пинать надо как-то.
Да, архитектура не идеальна. Это плата за очень высокую скорость разработки и нам приходится с этим пока жить )
Несколько датацентров, порядка 60-80 виртуальных машин в бою. Нагрузка 300 рпс в среднем на каждый фронтенд, есть пиковые даты в начале месяца. За фронтендом крутятся различные штуки — php-fpm, много раздатчиков статики в количестве 15 миллионов файлов, кучка постгресов. Различные кэши, где только можно — монга, редис, мемкеш. Spinxsearch поисковым движком и различные самописные узкоспециализированные демоны для локалсерча. Все это географически распределено по стране и зарубежью. Балансировка запросов сделана с помощью lvs, geo-dns. Отказоустойчивость на всех уровнях, начиная с датацентра. Сделано дублированием сервисов. Деплой, надеюсь, скоро будет идеальным, а это значит, что будет все равно куда деплоить и что. Будет плохо — полезем в облако, например.
Все завязано на наше ядро — API, проекты-сателлиты подключаются, как модули к этому ядру. Есть тенденция перевести на такую схему вообще все наши проекты. Но это тсс почти инсайд ))
Начинали мы с csync2 и с версионирования конфигов. Потом проектов стало чуть более одного, деплоили руками. Потом пригодился chef. Сейчас как-то так.
Ну вот не всегда, конечно же, мы же не роботы, а люди с эмоциями. Иногда не хочется, иногда просто сарказм. Так и минусовали бы такой комментарий, зачем карму трогать ))
ceph стабильный вроде как, ploop тоже. Для плуп надо лишь пересобрать vzctl, в pve собрали его с ключом --without-ploop.
Тут мы поставим рандек и сами нажмем кнопку, когда нам надо синхронизируем.
Rundeck это как Jenkins, но совсем для системного администратора, в таком ключе их можно сравнить. Мы все забилдили, надо выкладывать же. С десяток нод, есть среди них нетипичные и чем-то отличаются.
Рано или поздно процесс выкладки кода вообще перестает быть томным и сделать git clone (git pull) уже недостаточно, надо как-то сконфигурировать фреймоворк, подтюнить пхпшечку, подчистить кэш, но не весь. Чеф поможет.
Но чеф не умеет принимать во внимание связность компонентов. Допустим, обновить код на ноде только после того, как переиндексировался сфинкс и новые индексы уже залилились по всем нодам.
Момент такой, непростой, тоже помучались )
И пока мы вдруг не сталкиваемся с перегрузом и коэффициенты мультиплексирования перестают вдруг работать. Все тормозит и еле шевелится у всех. Тогда самую тяжелую виртуалку переселят на другую машину и все по новой.
Не везде дадут настроить тот же sysctl. Не везде дадут выбрать драйвера сетевой карты. Вот полно ограничений. Думаете в облаках какая-то другая виртуализация, чудесная и без проблем? Резиновая, не ломается, с моментальной миграцией, без колтрейсов ядра и вытекших виртуализованных девайсов ога.
В общем все понятно, еще один облачный теоретик.
Вы там, кстати, ниже евры посчитали. Это что, за трафик только? Давайте плюсанем остальные ресурсы, память там, цпу, диск IO и подберем еще коэффициент по пиковым нагрузкам.
CDN еще есть. Он, кстати, не весь трафик умеет жевать. Если его сложно классифицировать и кэшировать, то мс никаких не будет, если вообще возьмутся доставлять. Еще не забудьте приплатить за девяточки в SLA.
Сильно дешевле будет купить 8 штук VDS\VPS.
Мы сейчас точно про облака? Или про VDS\VPS?
Нет, я опираюсь на то, что половину всех действий мне просто не дадут сделать. Настройки не зависят? Да пусть даже не зависят. Облака — это те же самые виртуалки на хардварной ноде. Если я обнаглею и забью хардварную ноду по какой либо метрике, меня либо зашейпят, либо переселят. Это потеря производительности и простой в сервисе. За огромные бабки. За килобаксы. Даже не будем брать во внимание такой важный параметр, как скорость дисков.
Давайте попробуем решить.
Для размещения нам подойдет ubuntu. Раздавать будет nginx. Файлы положим на диск, раскидаем по дереву, чтобы у файлухи не сорвало башню. Также форматнем ее правильно, чтобы не кончились inode и правильно примонтируем. Памяти нужно много, чтобы под завязку использовать кеш, 16 гигабайт вполне должно хватить. Быстрый рейд на SAS 15k, чтобы все быстро читалось, когда кеш кончится. Надо также решить проблему с сетевым стеком, чтобы нам его не убило соединениями в состоянии TIME_WAIT, например. Подкрутим sysctl. Время ответа мы вроде обеспечим. Для отказоустойчивости нам желательно 4 таких ноды, желательно географически распределенных, из разных концов России latency разная, из Владивостока в Москву точно сильно долго ходить.
Посоветуете облако? Сколько мне надо денег в месяц, чтобы уехать в амазон с этим сервисом?
Хранилище «ультра». Скорость записи маловата мягко говоря? При этом даже такой вариант слегка недешевый.
Проксмокс, да, наш, как хотим так и вертим. Колтрейснулось ядро — починили. Мало мощности — добавили ноду. Смигрировали в другую по потребностям. Если наши задачи узко-специализированные, то никакой штат и опыт людей из черного ящика не помогут заточить ширпотреб, который для всех, под такие задачи. И никто кроме нас также не справится лучше.
Мне вообще нравятся минусующие, которые про облака все знают по маркетинговым статьям. Или за два доллара визиточку с 2 хитами в месяц хостили в амазоне.
По факту один только мой бекенд с php-fpm внутри, с агрессивным кэшированием, с общей нагрузкой 500rps не живет ни в одном облаке, мы их все почти перепробовали. И это максимальные планы за килобаксы. За вменяемые деньги нет ничего вообще. На секундочку, наши проекты — это в целом больше 10 миллионов уников в месяц, с пиками на начало месяца, когда надо 5 терабайт отдать за три дня.
Да и не приходится потом изливать негодование на хабре, когда тут некое пропиареное и облачное сутками лежит, а потом информацию уже не достать оттуда. Поищите, тут такого полно.
Делаем свои облака на базе proxmox.
А как же учебные части, военные институты и школы?)) В армии можно получить очень интересное и разностороннее образование, куда лучше, чем в некоторых наших ВУЗах. Правда очень специализированное и с трудом применимое где-то помимо армии.
Есть определенный порядок, уставные документы, детально описан порядок любых действий вообще. Что касается передачи закрытой информации — тем более. Все под учетом и на все есть инструкция. Ключи, блокноты, шифры, бланки, журналы.
Закрытое сообщение должно быть однозначным и зашифрованным вполне определенными средствами, гарантированной стойкости или временной. И если оно должно быть, значит оно таким и будет. Ответственность за неправильное\неподобающее использование шифров и закрытых средств связи всегда была и будет очень высока.
Во времена Второй мировой уже были придуманы стойкие и в тоже время простые в эксплуатации шифры, например, одноразовые блокноты Вернама. И ими пользовались вовсю. Как пользовались акронимами после 30х годов, например, я не слышал.
Предположить, что связист взял стандартный бланк для криптограмм, оформил его по инструкции, но при этом не взял шифровальный блокнот, вместо этого используя непонятные акронимы, можно, но как-то слишком притянуто. Такое может быть возможно, если надо было передать очень важную информацию, а запасы шифров уничтожены, например. Однако, голубиная почта — не очень надежно для очень важных сообщений. 10% сообщений просто терялось, как в случае с этим голубем. Сплошные нестыковки же.
В любом случае ничего мы гарантировать не можем и эта еще одна загадка так ей и останется ))))
Все шифры я не знаю, конечно же. Но знаю большинство, используемых военными во времена военных действий.
Да и так не шифровали никогда. Акронимы — это слишком неоднозначно. Когда высока неоднозначность — получается очень сложный ключ.
Что-то типа
— вот если буква К в начале слова и после гласной, то это know, а если hv и на дворе среда, то тогда это high velocity, но посмотрим сначала, если есть b в середине, то читать как have".
Кстати, смысла шифровать служебные глаголы, артикли и всякие служебные языковые конструкции, просто нет.
В итоге проще взять одноразовый блокнот. Ну и группки по пять букв как бэ намекают на нормальный фабричный шифр. Как и специальный фабричный бланк для шифрограмм.
И, кстати, что плохого собрать вообще все скрипты в один пакет, как например делает ZTC и ставить все разом, одним пакетом. Скрипты лежат, кушать не просят, а неразберихи меньше.
Сейчас надо либо писать сложные рецепты с обменом информацией через ohaio, либо каким-то образом дирижировать клиентами chef, чтобы они включались когда нужно и деплоили то, что нужно ) Если учесть, что ноды еще и не типовые из-за split тестирования, то довольно сложно разобраться что и где сейчас на бою. Рецепт вроде один, но json с аттрибутами уже не один. Иногда надо быстро что-нибудь отключить или передеплоить. А чефу не прикажешь же. Он висит и ждет. Либо его пинать надо как-то.
Да, архитектура не идеальна. Это плата за очень высокую скорость разработки и нам приходится с этим пока жить )
Все завязано на наше ядро — API, проекты-сателлиты подключаются, как модули к этому ядру. Есть тенденция перевести на такую схему вообще все наши проекты. Но это тсс почти инсайд ))
Начинали мы с csync2 и с версионирования конфигов. Потом проектов стало чуть более одного, деплоили руками. Потом пригодился chef. Сейчас как-то так.