-
Юбилейный DevConfX пройдет 21-22 июня в Москве. Как всегда — Вы решаете, кто попадет в программу секции Backend — голосуйте за интересные доклады
iWhore.ru - кто пробовал? отзывы
- Автор темы Фанат
- Дата начала
venet что ли?
Ivan Lungov
Новичок
По поводу этого и всех предыдущих даунтаймов, я написал развернутое эссе на серчах, если интересно, можете ознакомится о причинах возникновения сбоев и о том, как с ними боролись: https://searchengines.guru/showpost.php?p=15278794&postcount=1041
И мне кажется, что на фоне крупных даунтаймов в OVH, Selectel, PinSPB и Мегафона, наши 1:20 смотрятся очень скромно.
Также, раз уж зашел, напишу, что желание заходить на форум, где твой проект публично оскорбляют в названии темы - равно нулю. Подмена названия только из-за схожести звучания с нелицеприятным словом в одном из нескольких тысяч языков существующих на Земле (пускай и популярном) и демонстрация "остроты своего ума" на публику, говорит, лишь, о незрелости сознания данного индивидуума, не наделенного чувством такта и воспитанием.
В IT-сфере, которая по сути является одной из сложнейших сфер деятельности человечества на текущий момент развития цивилизации, и которая пронизывает все остальные сферы деятельности человека, очень трудно обойтись без сбоев. Я ни за что не поверю, что ваши разработки на PHP пишутся сразу идеально, без единой ошибки, без единого бага, и всегда работают без единого сбоя. Посему, мне не ясна причина столь откровенного выражения неприязни к хостингу, который уже занимает 26 место на российском рынке. Если вам что-то не нравится, то просто удалите эту ветку и все упоминания о нашей компании со своего ресурса. Иначе, таким названием темы вы позорите только самих себя и заявляете всем, что тут собрались не серьезные специалисты, а, скорее, несмышленые дети.
В целом, мне уже давно глубоко параллельно на любые оскорбления в мой адрес или в адрес моего дела, поэтому, все написанное выше, можно расценивать исключительно как взгляд со стороны.
И в заключении, выдержка о значении слова ИХОР найденная мною на одном сайте:
Ivan Lungov
Новичок
Миграция идет по одному контейнеру, в ручном режиме и в ночное время. Системы виртуализаций разные и штатного средства миграции у панели управления нет. До конца месяца все будут перенесены. На текущий момент осталось 48 контейнеров.из 106, больше половины клиентов уже отмигрировали.
Да название темы не ахти, публично хочу извиниться, хоть и не я автор
решил исправить да простят меня старожилы, который сами в результате хотятся у Вас и не хотят сьезжать ;-b
Претензии не к Вам, Иван.
Претензии к процессу и реагировании на проблемы
тех кто доверил свои данные и данные текущих
и будущих клиентов.
Мне иногда кажется что Вы работаете за себя и за того парня,
вот это не совсем правильно. Вы уже большая и популярная
компания - надо что-то в консерватории менять IMHO.
решил исправить да простят меня старожилы, который сами в результате хотятся у Вас и не хотят сьезжать ;-b
Претензии не к Вам, Иван.
Претензии к процессу и реагировании на проблемы
тех кто доверил свои данные и данные текущих
и будущих клиентов.
Мне иногда кажется что Вы работаете за себя и за того парня,
вот это не совсем правильно. Вы уже большая и популярная
компания - надо что-то в консерватории менять IMHO.
"А у вас негров линчуют"!
Как мне видится, проблема не столько в даунтаймах, сколько в отсутствии информирования. Почему-то в exUSSR многие стараются замалчивать об авариях: авось не заметят.
У того же ovh (хотя на что уж помойка) есть вот такая страничка, где вся информация о сбоях общедоступна: http://status.ovh.net/
У селектела, кстати, тоже (молодцы какие): http://status.selectel.info/
А у вас?
Ivan Lungov
Новичок
Спасибо ), только "e" в конце лишняя
.В большинстве случаев проблем с реагированием нет. Но бывают и задержки, к сожалению. Процессы работы команды постоянно оптимизируются и процент задержек постоянно падает. Если возникают какие либо сложности можно писать мне в личку. Я открыт для прямого общения практически с любым клиентом и стараюсь реагировать на любые замечания (Как и сделал в этот раз в этой теме). Это мне дает, как минимум, понимание того, что от нас хотят клиенты, что еще нужно улучшить.
На самом деле это не так, у нас уже большая команда и все стараются работать на результат, всем интересно, просто работы реально много и в каких то местах возникают ошибки, но мы их стараемся оперативно устранять.
Ваш проблемный случай возник на маленьком островке устаревшего сегмента наших услуг. В этом году мы полностью закрыли продажи на кластера с виртуализацией OpenVZ и занялись плавным переносом клиентов на KVM. Развитие технологии OpenVZ практически застопорилось на уровне разработчиков и это приводит к накоплению багов, которые некому исправлять. Одним из таких багов стало периодическое отваливание сети внутри контейнера, которое и лечится только ребутом контейнера. На момент возникновения бага у нас оставалось всего около 100 OpenVZ-контейнеров. При общем количестве VDS в 12 тысяч, это составляет всего 0.8% от общего числа клиентов, которые потенциально подвержены этой проблеме.
Я понимаю, что попасть в это число все равно не приятно, тем не менее, как видите, мы стараемся максимально быстро реагировать и переносить тех, у кого проявляется данный баг в приоритетном порядке. На текущий момент осталось перенести всего 40 контейнеров. До конца года, данная проблема уйдет в историю. Виртуализация KVM активно поддерживается мировым сообществом разработчиков и наши админы регулярно просматривают баг-листы и обновляют гипервизоры. Стабильность работы VDS KVM на порядок лучше, особенно прикрытое собственным анти-ддос решением
. Также, в качестве бонуса, все клиенты с OpenVZ, переезжают на новые машины с процессорами Intel Xeon E5. Напомню, что на старых серверах у нас стоят CPU Xeon E5620. По этому все будет работать и стабильнее и быстрее .Если уважаемое сообщество phpclub, готово к конструктивному диалогу, то я готов регулярно заглядывать сюда. Отвечать на вопросы, помогать в решении возникающих проблем, постить наши новости для более удобного восприятия.
Пока нет, к сожалению, но в планах стоит задача по выводу всех основных параметров с нашего внутреннего мониторинга в паблик. Начиная от работы инженерных систем наших дата-центров и заканчивая аптаймом и нагрузкой конкретных серверов. В настоящий момент мы ведем разработку нового сайта, который уже будет тесно интегрирован с нашими системами, это и позволит оперативно выводить всю информацию в удобном виде.
Ну а пока, в случае серьезных проблем я лично веду трансляцию с места происшествия, как это было 30 сентября ). Запись трансляции доступна на нашей странице в VK. Заодно и экскурсия по ДЦ получилась ).
Это все может быть интересно, но конечного потребителя по факту интересуют не детали инженерных систем, и уж тем более не трансляции в социалочках, а что сломалось и когда заработает.
Для этого не надо разрабатывать сайты и системы мониторинга, достаточно воспользоваться готовым сервисом: https://www.statuspage.io/
michelle
Новичок
Тоаврисч дорогой, а как этим сервисом мониторить серые сети?
А если нужно мониторить"нестандартные" для того сервиса вещи?
Пока что лучше заббикса, нагиоса и им подобным не вижу.
ПоправилСпасибо ), только "e" в конце лишняя
Я понимаю, что попасть в это число все равно не приятно, тем не менее, как видите, мы стараемся максимально быстро реагировать и переносить тех, у кого проявляется данный баг в приоритетном порядке. На текущий момент осталось перенести всего 40 контейнеров. До конца года, данная проблема уйдет в историю. Виртуализация KVM активно поддерживается мировым сообществом разработчиков и наши админы регулярно просматривают баг-листы и обновляют гипервизоры. Стабильность работы VDS KVM на порядок лучше, особенно прикрытое собственным анти-ддос решением
Как - то странно переехало, в панели стоит kvm - но dmesg и прочие команды как в OVZ ;-)
В таких случаях (я про залипание) хотелось бы не мониторит самому - а чтоб админы написали скрипт который при потере пинга перезапускал контейнер, раз проблема на хост машине.
Как вариант - предлагать самостоятельно переехать, просто когда хостинг оплачен на год вперед - непонятно как это сделать.. выдавать временный контейнер на 3 дня к примеру с аналогичными характеристиками.
Да казусы бывают - тут долго(неделю!) доказывал одному из провайдеров что у них SSD посыпался - в контейнере выглядить как отваливание sda при бекапе. В результате оказался прав и пришлось с пешном порядке мигрировать на другую хост машину.
Но имя диска сменилось на какое-нибудь vda?
Там же миграция заключается фактически в ручном создании образа, полном заливании туда содержимого контейнера openvz, накатывании ядра и загрузчика.
Оттуда и остатки ovz.
Ты ничего не понял, это не сервис мониторинга.
Ivan Lungov
Новичок
Ну это смешанные данные, и мониторинга и прогресса по решению инцидентов. Данные с мониторинга по любому должны браться автоматизированно да и изменение статуса и прогресс-бара по решению проблемы тоже должно быть максимально автоматизированно. Вообщем, сначала мы переделываем сайт, в его архитектуру уже будет заложена интеграция с нашими системами. После этого появятся и статусы.
Ivan Lungov
Новичок
Могу создать еще один VDS с аналогичными параметрами, для проведения чистого переноса, сами справитесь?
Вот уж это вечное желание программистов "заложить в архитектуру". А потом отмазываться, что нечто сделать нельзя, потому что "в архитектуру не заложили". Вот видите, даже я (программист) критикую такой подход, отвечая, вроде как, менеджеру.
Как клиента, меня абсолютно не волнует, что у вас там автоматизировано, а что нет. Для меня пользу представляет информация об инцидентах и сроках решения проблем, каким образом она публикуется - мне все равно.
Я, конечно, могу ошибаться, может, за время пути собачка могла подрасти, и у вас там 50 датацентров по всему миру, но мне кажется, что масштабы все таки меньше. Вряд ли инциденты происходят ежечасно. В случае же, когда они происходят, мне кажется, нет никаких проблем с тем, чтобы сотрудник техподдержки добавил статус на сайт - тем более, что можно пользоваться заранее созданными шаблонами: это вряд ли займет более одной минуты. Более того, любая автоматизация может дать сбой, и ручное размещение информации об инцидентах - необходимая функциональность.
Логично было бы начать с того, чтобы сделать возможность ручного размещения. А уже потом можно то же самое API дергать и из мониторинга. Опять же, даже ничего делать не надо, достаточно заплатить за какой-нибудь существующий сервис, который такие возможности предоставляет - тем более что такой сервис работает в независимых от вас датацентрах, и даже если у вас все вдруг совсем накроется, будет доступен.
vadim s. sabinich
Новичок
Я даже зарегистрировался на форуме чтобы ответить. Ну и с тайным желанием таки овладеть phpПоправил
Как - то странно переехало, в панели стоит kvm - но dmesg и прочие команды как в OVZ ;-)
Исходя из того, что на openvz у нас живут очень давно и, иногда, с довольно экзотическими уже версиями дистрибутивов, то мной было принято решение миграции ovz -> kvm следующим образом (исходя из того, что ovz-прослойка крайне мало потребляет ресурсов): на kvm-кластере создаётся виртуальная машина, которая будет играть роль хоста. Внутри настраивается openvz-окружение и стандартными методами vzmigrate мигрируется целиком весь контейнер клиента. Без каких-либо изменений его состояния. После этого "железный" интерфейс хоста прокидывается в ovz-контейнер и всё работает. Для администрирования хоста можно использовать vnc.
В дальнейшем этот контейнер можно увезти куда угодно, вплоть до выделенного сервера без каких-либо изменений содержимого.
Тут выше описывался метод переноса через rsync. Могу сказать, что этот метод тоже работает, но это прямое вмешательство файлов клиента, изменения root-пароля и тому подобное.
Мы решили от этого уйти и пока никто не жаловался после переезда на какие-либо ухудшения.