sergv, зависит от типа нагрузки. Создайте, пожалуйста, тикет в отдел технической поддержки, Вам обязательно помогут.
Благодарю Вас.
REA-white, спасибо за Ваш интерес к нашим услугам! Услуга не новая и уже обкатанная, просто текущее оборудование ресурс по количеству VPS исчерпало, в данный момент ожидаем поставки нового хост-сервера.
Relapse, к сожалению, предсказать kernel panic (на примере Windows - синий экран смерти, BSOD) возможности никакой нет, поэтому мы не можем заранее предупредить наших клиентов о надвигающейся проблеме. Для нас она также неожиданна, как и для Вас.
Искренне сожалею, что Вы столкнулись с подобной ситуацией. На хост-серверы установлены последние патчи для стабилизации их работы.
Relapse, сожалею, что Вы столкнулись с подобной ситуацией. Насколько я вижу, в тикете #966388 Вам уже подробно объяснили ситуацию. Повторю это объяснение на форуме:
К сожалению, на хост-сервере, на котором расположен Ваш сервер, действительно произошел сбой, а именно kernel panic. Подобной ситуации предсказать нельзя, она происходит внезапно, из-за какой-либо ошибки в ядре ОС, поэтому работу идут внеплановые (т.е. не запланированные). Сами работы заключаются в сохранении crash-дампа, аппаратной перезагрузки хост-сервера, загрузки хост-сервера с последних стабильных версий ПО, и корректного запуска клиентских контейнеров.
Сам kernel panic это сообщение о критической ошибке ядра операционной системы, после которой операционная система не может продолжать дальнейшую работу. Т.е. происходит аварийная остановка работы всех процессов хост-сервера и процессов виртуальных серверов. При этом действительно может происходить потеря данных, которые не были успешно записаны на диск, так как процесс записи данных немного сложнее, чем просто "взяли и записали". Грубо говоря, ОС Linux оперирует различными буферами и кэшами при работе с данными для ускорения с ними. Помимо этого у приложений есть также свои механизмы для оптимизации работы с дисковой подсистемой.
На примере сервера MySQL:
Ознакомиться как именно MySQL работает с диском и какие опции для изменения этого поведения есть у сервера MySQL можно в документации по ссылкам https://dev.mysql.com/doc/refman/5.7/en/innodb-disk-io.html и https://dev.mysql.com/doc/refman/5.7/en/optimizing-innodb-diskio.html
По умолчанию, сервер MySQL пишет и читает данные в RAM памяти и периодически эти данные из памяти сбрасываются на диск. Помимо этого есть также буферы файловой системы, планировщик I/O в ОС, которые в итоге также влияют на итоговый реальный момент сброса (записи) данных на диск. Если в момент, когда сервер MySQL изменил данные в буферах, но еще не произвел сброс данных на диск, произойдет крах процесса MySQL (или всей ОС (как kernel panic на хост-сервере) или обесточивание сервера), то данные, находящиеся в буферах, будут полностью утеряны.
К сожалению, от kernel panic застраховаться не возможно, идеального безошибочного ПО, такой сложности как ядро Linux, нет. Хочу обратить внимание, что от ошибок не застрахована и аппаратная часть, например http://www.computerra.ru/138414/intel-skylake-cpu-bugs/
Снизить риски потери данных при таких ситуациях можно различными методами (в том числе и в комплексе), например более тонкой настройкой сервера MySQL, например корректировкой флагов innodb_flush_method, innodb_flush_log_at_trx_commit и прочих. Также можно настроить репликацию данных сервера MySQL на резервный сервер. Для исключения влияния системы виртуализации мы можем порекомендовать использовать выделенный физический сервер, что позволит отказаться от дополнительной программной прослойки, которая также может вносить вероятность ошибки (если рассматривать выделенный физический сервер и выделенный виртуальный сервер, то под виртуальным сервером есть еще программная прослойка, обеспечивающая работу виртуальных серверов).
Также, мы убедительно просим Вас и остальных клиентов любого хостера делать необходимое количество независимых бэкапов с требуемой для Вашего проекта периодичностью.
Мы искренне приносим извинения за неудобства, которые были Вам доставлены из-за падения хост-сервера. Мы прикладываем максимум усилий для минимизации подобных ситуаций и активно сотрудничаем с производителем используемой у нас системы виртуализации для исправления всех найденных ошибок и не допущения их в будущем. За последний год нашими инженерами было зафиксировано и сообщено около 300 проблем, информацию можно найти в баг-трекере https://bugs.openvz.org/
Благодарим Вас за выбор FASTVPS.
Silva, большое Вам спасибо за теплые слова и за выбор FastVPS, очень приятно. :)
234sha, понимаю Вашу озабоченность по данной ситуации.
По данным типам жалоб блокировки сервера не производится (с ДЦ договоренность по данному вопросу достигнута).
Мы не абузоустойчивый хостинг, поэтому все обращения мы пересылаем и ждем от наших клиентов реакции на эти обращения.
Вашей реакции на указанную жалобу о несогласии с ней было бы более чем достаточно.
Благодарим Вас за содействие и реакцию в тикете.
Формулировка в тикете действительно пугающая на данный тип жалоб, приносим извинения. К сожалению, у нас пока нет возможности дифференцировать поток жалоб от ДЦ и все они пересылаются как есть с одним шаблоном.
Спасибо за выбор FastVPS! Успехов Вам и Вашим проектам.
vitaly_m, спасибо за Ваш вопрос. Каждый случай атаки рассматривается вместе с клиентом индивидуально и ищется взаимовыгодное решение вопроса. Полный дамп сервера мы выдаем, возврат средств производится согласно договора-оферты.
cjseriy, давайте продолжим общение по Вашему вопросу в тикете. Благодарю Вас.
DarkEmpire, к сожалению, услуг по защите от DDoS мы не предоставляем. По данному вопросу рекомендуем обращаться в профильные компании. По умолчанию, при серьезной атаке доступ к серверу блокируется, далее уже по ситуации выбираются конкретные решения, что именно делать. Все очень индивидуально.
cjseriy, как все верно сообщил Alex91, можно поставить Debian 6 + ISPManager 4 Lite + PHP 5.2 из репозиториев ОС Debian 5 (типичный пример, способов установки множество, например в посте я показывал пример сборки сторонней версии PHP, такую установку можно провести и на актуальной ОС). Однако обращаю особое внимание на то, что данное ПО устаревшее и не поддерживается производителем, соответственно Ваши данные постоянно будут под угрозой (заражения или полного удаления). Мы настоятельно рекомендуем использовать только актуальное и поддерживаемое производителем ПО для снижения рисков угрозы Вашим данным.
Сообщите, пожалуйста, номер тикета, в котором шло обсуждение вопроса. Посмотрю, почему Вам отказали.
alligator77, к сожалению, с нашей стороны действительно произошла ошибка при обработке Вашего вопроса. Примите наши искренние извинения.
Возврат за неиспользуемую услугу сделали.
Приятной Вам работы.
alligator77, уточните, пожалуйста, номер тикета, в котором шло обсуждение вопроса.
