Комментарии 25
Ну и можно неприличный вопрос? А почему mysql, а не postgres?
Детали, как это работает, потянет на целую статью. Думаю, напишем и про это.
Если коротко. Есть много (под сотню) различных БД с четко ограниченной предметной областью, там используется с master — standby репликация. Еще есть одна большая БД, которую еще не растащили по небольшим базам. Эта БД собрана в «гирлянду», т.е. ветвистое дерево master-slave-slave… В случае падения мастера github orchestrator промоутит (снимает флаг read-only), на его место или единственный standby инстанс, или одну из реплик гирлянды (по хитрым правилам) и перестраивает остальные, чтобы те тянули данные с нового мастера. Proxysql ориентируются на флаг read-only на mysql и меняют состав своих хостгрупп. Сами proxySQL подняты с одним и тем же IP в разных локациях, поэтому при отказе одного, запросы начинают уходить к соседям.
Второе:
Наверное, правильный ответ “так исторически сложилось”. Когда-то давно выбрали MariaDb, с тех пор парк разросся, внутренняя экспертиза прокачалась, а с postgress практического опыта почти нет. Поэтому пока только аккуратно присматриваемся, но не переезжаем.
Именно свое железо это 4 стойки в ЦОДах и в офисе еще есть, но чуть поменьше. В основном пара вендоров, но бывали эксперименты с другими производителями, не зашло нам. В целом, строгих ограничений нет, но плодить зоопарк тоже нет желания — хочется без сюрпризов:)
А почему остановились именно на вендорском клауде? Почему не тот же opennebula/cloudstack/openstack/vmware поверх commodity железа?
Основное: уровень требуемой экспертизы для нормальной и надежной работы этих решений. Мы несколько лет назад игрались с кластеризацией поверх обычных серверов, все время что-то шло не так и не туда. Мы же все таки для себя решение строили, а не для зарабатывания на нем. Поставил, запустил и полетели (не так, конечно, получилось, но близко к этому). От начала проекта до выхода в прод 4-5 месяцев получилось, что очень неплохо.
Но как писал в комменте уже, сейчас в проработке проект OpenShift on Bare Metal. Хотим свое облако с микросервисами на обычном железе попробовать разместить.
Опеншифт ради чего? Безопасность, поддержка редхата — или какая причина смотреть на него?
Или думаете брать бесплатный шифт?
К сожалению, не могу согласиться. Мы с коллегами из того же Фланта обсуждали перспективы Шифта… И они топят все-таки за ваниль. Шифт очень opinionated. Хотя в нем и многие проблемы решены, но шифт не гибок.
Касательно того, с чем столкнетесь с шифтом:
- в него прекрасно заезжают ваши самописные сервисы (в общем-то он для этого и предназначен)
- засунуть в шифт что-то, что для него не предназначено — это отдельный секс. Любой гитлаб, постгрес, редис и пр. из официальных хельмов и докерхабов нужно умудриться поставить
- опеншифт очень платен, как вы будете его масштабировать — я вообще не представляю. А бесплатный… Ну, такое себе.
- ограниченный набор плагинов — из кубернетеса Вы действительно можете слепить что угодно (это же и проблема на самом деле). Опеншифт — это коробка. Т.е. Вы получаете ровно тот функционал, который там есть. Отклонения в сторону… ну, либо снимут с поддержки, либо будет отдельная боль с интеграцией доп модулей.
- отсутствие понимание как опеншифт будет развиваться. Уже были примеры, когда функционал появлялся в шифте, потом в кубернетесе, но другой. Например, в шифте были Route, в куб затащили Ingress. В результате, в шифте все равно придется переезжать на Ингресс. С сетевыми политиками та же история.
Если уж Вы строите из себя энтерпрайз, то лучше посмотрите в сторону Vmware и Vmware Tanzu (у них свой менеджед кубер есть по сути в Вашем контуре) :-)
И прочее-прочее-прочее.
Во-первых, нужны гарантии по задержкам сети, что с публичными сетями бывает проблемой. А во-вторых, и это важнее, оптика дешевле выходит. У нас в одной из локаций был резерв по VPN (делали временно, пока второе плечо оптики вводили). Так вот в момент той самой аварии из статьи, когда в одном колодце пожар, а во втором «какой интересный коннектор», этот гигабитный канал не вытянул. По факту у нас 3-4 Гбит/с между локациями ходит. А такие аплинки дороже оптики получаются.
В сторону облачных контор а-ля AWS не смотрели из-за ФЗ, или какая-то своя причина была?
Яндекс.Облако также не рассматривали из-за финансовой невыгодности? И, на самом деле, была бы интересна арифметика — "на колокейшене со своим железом тратим столько-то, в облаке бы тратили вот столько-то", например.
Ещё любопытно почему на одном кластере есть мастер, на другом слейв, а на третьем нету ничего, но на всех есть приложение. Групповая репликация с хранением копии под каждой репликой приложения также не могла быть применена по каким-то причинам?
2. К моменту появления Я.Облака у нас уже было два провайдера облаков, третий не нужен. Тратить ресурсы на «давайте еще попробуем вот это», когда с действующими поставщиками все нормально, нецелесообразно. Наш проект на своем HCI окупается примерно за год. Я считал NPV на 4 года, сравнивая одинаковые объемы ресурсов в облаке и у себя. Кстати, сейчас мы работаем над проектом OpenShift on Bare Metal: идея в том, чтобы развернуть OpenShift на самом обычном железе, а не на HCI или облаках. Просчитываем варианты, если получится, поделюсь.
3. Тут скорее вопрос целесообразности и экономики. Можно поднять и три, и четыре копии (на некоторых особо критически важных базах так и делаем). Все-таки вероятность одновременного отказа двух сильно ниже, а деньги на инфраструктуру надо выделять. Изначально так и хотели делать (по копии в каждой локации), однако известные события весны этого года скорректировали аппетиты :)
В частности, производительность по факту не такая прикольная как в презентациях из-за оверхеда.
Можете прояснить, что не так с производительностью Делла? Это какая-то доступная информация или ваши наблюдения?
Наверняка есть способы это побороть, но мы искали решение, которое требует меньше танцев с бубном. Кроме того, мы остались не очень довольны уровнем технической поддержки Dell, а это тоже очень важно, когда покупаешь очень дорогое оборудование.
Как мы разгребаем зоопарк из 5 размещений в дата-центрах