- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
Все что нужно знать о DDоS-атаках грамотному менеджеру
И как реагировать на "пожар", когда неизвестно, где хранятся "огнетушители
Антон Никонов
VK приобрела 70% в структуре компании-разработчика red_mad_robot
Которая участвовала в создании RuStore
Оксана Мамчуева
странно, на мои тикеты реагируют в течении 5-15 минут. А в целом хостинг VDS понравился ,щяс хостинг PHP юзаю, тож вроде все пристойно.
---------- Добавлено 27.04.2015 в 12:56 ----------
доступа по SSH нету, это минус
В "круглосуточную тех.поддержку" я не смог дозвониться в течении часа - до сих пор трубку не берут. Тикет висит, без адекватной реакции. Собственно, вот и весь отзыв. Перевожу критичные проекты на другой хостинг, устал ловить такие чудеса в самый неподходящий момент.
Добрый день.
Дело в том что офисный телефон исключительно для финансово - юридических вопросов. Нигде не написано что мы осуществляем тех. поддержку по телефону. Да ,есть случаи, когда помогаем и по телефону, но это скорее исключение, когда есть свободные инженеры. Так же большая просьба при общении с технической поддержкой не использовать нецензурные выражения. Запрос от вас пришел 08:09:17, ответ в 08:18:08 - что показывает приемлемую скорость работы тех. поддержки. Но даже не в этом суть. Вы называете услугу "хостингом", думая что мы предоставляем хостинг. Мы же сдаем в аренду виртуальную машину, которая является для нас черным ящиком. Если у вас происходят проблемы внутри виртуальной машины - в чем мы виноваты ?
странно, на мои тикеты реагируют в течении 5-15 минут. А в целом хостинг VDS понравился ,щяс хостинг PHP юзаю, тож вроде все пристойно.
Напишите в тех. поддержку, рассмотрим возможность предоставления доступа по SSH.
Ситуация получилась весьма и весьма напряженная. Контейнер ночью работал штатно, без сбоев. Разработчики трудились, проблем не было. Все показатели были в нормах.
Утром началась активная работа с заказчиками - и тут выясняется (от недовольства пользователей), что ФС в рид-онли. Т.е. я даже не сразу понял, откуда это могло такое стать. Пользователи в шоке, а клиентам не можем выкатить проект в паблик.
Ребут с фсчеком не помог ввиду того, что /tmp вообще в принципе не мапился - ругался на его отсутствие как таковое. Я в этот момент был подключен по VNC и просто не успел сделать скрин. Успел только заскринить начальные маты убунты на неконсистентность ФС.
При этом при всём - внутри контейнера ничего внештатного не происходило.
Решилось спустя почти два часа от возникновения проблемы в тупую миграцией на другую ноду.
И после миграции всё заработало опять в штатном режиме.
Вот как это назвать? И кто виноват?
И как так получается, что ситуации происходят в самые неприятные моменты?
Ладно бы ночью в воскресенье, или там после обеда... Но утром!!! В понедельник!!!!! Это просто жесть.
Решилось спустя почти два часа от возникновения проблемы в тупую миграцией на другую ноду.
И после миграции всё заработало опять в штатном режиме.
Здравствуйте.
Сотрудник службы поддержки Руслан, сегодня отвечал на ваш запрос.
Касательно миграции, речь шла о миграции 4 марта, сегодня я не производил каких-либо операции подобного рода. Манипуляции которые наблюдали вы в VNC производил так же я, о чем оповестил вас в тикете, именно это и было решением проблемы.
Ситуация получилась весьма и весьма напряженная. Контейнер ночью работал штатно, без сбоев. Разработчики трудились, проблем не было. Все показатели были в нормах.
Утром началась активная работа с заказчиками - и тут выясняется (от недовольства пользователей), что ФС в рид-онли. Т.е. я даже не сразу понял, откуда это могло такое стать. Пользователи в шоке, а клиентам не можем выкатить проект в паблик.
Ребут с фсчеком не помог ввиду того, что /tmp вообще в принципе не мапился - ругался на его отсутствие как таковое. Я в этот момент был подключен по VNC и просто не успел сделать скрин. Успел только заскринить начальные маты убунты на неконсистентность ФС.
При этом при всём - внутри контейнера ничего внештатного не происходило.
Решилось спустя почти два часа от возникновения проблемы в тупую миграцией на другую ноду.
И после миграции всё заработало опять в штатном режиме.
Вот как это назвать? И кто виноват?
И как так получается, что ситуации происходят в самые неприятные моменты?
Ладно бы ночью в воскресенье, или там после обеда... Но утром!!! В понедельник!!!!! Это просто жесть.
Видимо что то с дисковым массивом случилось. Возможно просто закончилось свободное место на ноде под контейнеры, после последних выполненных бекапов.
Видимо что то с дисковым массивом случилось. Возможно просто закончилось свободное место на ноде под контейнеры, после последних выполненных бекапов.
Что значит закончилось место?
При виртуализации KVM, диск выделяется блоком, согласно тарифа и монтируется как LVM-том.
Не путайте с OpenVZ-виртуализацией, где, в принципе можно оверселить диск. Здесь, с нашей стороны, ресурсы были выделены в полном объеме. По этому, место могло закончится только внутри контейнера, но никак не снаружи его.
---------- Добавлено 27.04.2015 в 21:10 ----------
Ситуация получилась весьма и весьма напряженная. Контейнер ночью работал штатно, без сбоев. Разработчики трудились, проблем не было. Все показатели были в нормах.
Уважаемый, tlk, я внимательно перечитал Вашу переписку с тех. поддержкой. В данном случае, мне даже не за что их упрекнуть. С нашей стороны, никаких сбоев не было, все работало в штатном режиме. Ребята из поддержки отвечали быстро и корректно.
В 08:09:17, от Вас поступил запрос. В 09:39:46, Руслан написал, что исправил проблему. В 10:02:35, Вы подтвердили, что все работает. Причем, судя по переписке, первый час из этих полутра часов ушел на попытку получить от Вас доступ к Вашему VDS. То есть, решение самой проблемы уложилось в 30 минут.
Ребут с фсчеком не помог ввиду того, что /tmp вообще в принципе не мапился - ругался на его отсутствие как таковое. Я в этот момент был подключен по VNC и просто не успел сделать скрин. Успел только заскринить начальные маты убунты на неконсистентность ФС.
Как раз именно reboot+fsck и помог устранить проблему. Проблема образовалась внутри Вашей файловой системы, а не на мастер-ноде. То есть, по факту, это Ваша епархия, к которой мы доступа не имеем. Как вариант, файловая система могла быть повреждена Вашими разработчиками, но это лишь мои предположения. Можете у них поинтересоваться, какие действия они проводили на сервере до возникновения проблемы. Возможно, это прояснит ситуацию.
Решилось спустя почти два часа от возникновения проблемы в тупую миграцией на другую ноду.
И после миграции всё заработало опять в штатном режиме.
Про время решения, я написал Выше. Ваш сервер никуда не мигрировали. Все что было сделано, это reboot+fsck. Тоже самое, Вы могли сделать самостоятельно, не обращаясь в тех. поддержку.
Вот как это назвать? И кто виноват?
И как так получается, что ситуации происходят в самые неприятные моменты?
Я бы начал поиск виновного с разработчиков.
В среде профессиональных разработчиков есть следующее правило, никогда ничего не запускать в продакшн в пятницу и в понедельник. В первом случае, некому будет исправлять ошибки на выходных. Во втором случае, понедельник - день тяжелый. Лучше еще раз все проверить. Потом, никогда не производить разработку на продакшн-машине. Для этого, всегда должна быть тестовая среда.
Немного подытожу:
1. Телефон офисный, в основном для консультаций и решения орг-вопросов. Время работы с 10 до 18 часов, оно, официально указано на сайте: http://take.ms/qKpRL, также, указаны категории решаемых вопросов. Последнее время, часто отвечаем до 2-3 ночи. Поскольку часто засиживаемся на работе допоздна. Но рабочий день у сотрудников, которые приходят с утра, начинается в 10 часов. Тех. поддержку по телефону оказываем только по мере возможности и наличия свободных инженеров. В последствии, будем вводить тех. поддержку по телефону, но пока приоритет на тикет-систему. И как видно из переписки, нам удалось отладить ее работу на достаточно хорошем уровне.
2. /tmp, директория внутри Вашего сервера, к мастер-ноде, никакого отношения это не имеет. При использовании аппаратной виртуализации KVM, наличие или отсутствие свободного места на мастер ноде не может никак повлиять на работу VDS, поскольку дисковое пространство выделяется согласно тарифу при создании виртуальной машины. Если места нету то машина просто не создастся. Если есть, то все место резервируется сразу, таким же образом, как Вы разбиваете диск на своем компьютере и указываете какого объема будет тот или иной раздел и Вы не сможете создать логических дисков суммарным объемом больше, чем есть на физическом носителе.
3. При возникновении проблемы, лучше сразу, в первом же запросе, предоставить все необходимые данные для доступа к VDS. Как видно выше, это может сэкономить достаточно много времени. Единственный вариант у тех. поддержки получить доступ к Вашей машине не зная пароль, это остановить ее, отмонтировать диск, примонтировать его на мастер ноде, сменить пароль, отмонтировать его, снова примонтировать к Вашему VDS и запусить его. Но на все это, тоже нужно время. Проще, предоставить текущие доступы, а по окончании работ просто сменить пароль.
Прошу все выше написанное, воспринимать не как обвинение/оправдание, а исключительно как комментарий. Хостинг, достаточно сложная услуга и при ее использовании, клиенту, все таки необходимо иметь знание базовых принципов работы, это позволит гораздо быстрее и с меньшими затратами нервов решать возникающие проблемы. Не важно, нашими услугами Вы будете пользоваться или чьими то еще.
---------- Добавлено 27.04.2015 в 21:31 ----------
Интереса ради - а какое соотношение активных серваков с ovz и kvm?
Из 2034 VDS активных в данный момент, OpenVZ составляют всего 210. Так что, сильный перевес в сторону KVM. Правда, OpenVZ у нас, только на HDD.
Вам наверно нужно убрать линейку OpenVZ и KVM HDD. Тех. поддержки было бы удобнее, как одна виртуализация удобнее в плане настройки и поддержке, а SSD в плане скорости и ограничениях.
Скорее всего, закроем со временем. Но сделаем это естественным путем. По сложности поддержки, особых проблем нет. Как говорится, каши не просит. От HDD, скорее всего будем вообще отказываться. Поскольку это не выгодно и бесперспективно.
Кстати как ведут себя SSD диски? Просто интересно узнать о них подробнее, есть ли разница по сравнению с дисками Intel, которые в 2 раза дороже.
Вполне нормально, скорость высокая. Износ (циклов записи) не высокий. Отказов, за полтора года ни одного. HDD, уже кучу поменяли.
А когда вы планируйте запустить новый дата центр? Только побольше, и желательно с новым парком оборудования, чтобы гордо говорить, "почувствуй разницу", а она есть, правда в подсчетах невидна, только в тестах.
Работаем над этим ;).
И ещё вопросик, вы чуть выше писали что разрабатывайте свой собственный биллинг, вам не нужна помощь в этом плане, даже можно в другом, панели управления хостингом или vds? Могу помочь.
Скажу главному разработчику. Он свяжется с Вами.
Зы. На KVM есть увеличения ресурсов на лету и живая миграция.
Живой миграцией пользуемся каждый день. Увеличение ресурсов на лету отрабатываем для внедрения в свою панель.
Вполне нормально, скорость высокая.
Три месяца назад скорость еще можно было назвать относительно высокой (примерно 140 мб/c). Месяц назад скорость была ~80 мб/с.
Сегодня скорость 43 мб/c. Как вы думаете, это быстро?
Три месяца назад скорость еще можно было назвать относительно высокой (примерно 140 мб/c). Месяц назад скорость была ~80 мб/с.
Сегодня скорость 43 мб/c. Как вы думаете, это быстро?
Как то так...
[root@ ~]# time sh -c "dd if=/dev/zero of=ddfile bs=8k count=500000 && sync"
500000+0 records in
500000+0 records out
4096000000 bytes (4.1 GB) copied, 24.7277 s, 166 MB/s
real 0m27.933s
user 0m0.156s
sys 0m9.011s
Как то так...
4096000000 bytes (4.1 GB) copied, 24.7277 s, 166 MB/s
Завидую вам... А у меня всё медленней и медленней...