Minorov: С учетом принятого закона о хранении личных данных не вижу смысла держать сайты за рубежом, чтобы потом обратно переносить в РФ.
Поэтому из этих двух - ihc
+ есть подозрения, что фоззи та же контора, что и макхост с евробайтом.
Фоззи не связан с макхостом и евробайтом, инфа 100% - есть хорошо знакомые люди там.
Чаще всего да. Но современные сервера даже без особых хитрых антиддосов при включенных син-куках приличные SYN-атаки держат без проблем. Либо не очень сложно допиливается свое решение на базе фреймворка NETMAP, но там надо немного пописАть.
У нас атакуют постоянно клиентов с игровыми серверами. Причем атаки достаточно однообразные, которые особых проблем не доставляют: 5-15 Гбит/с (UDP fragmentation, UDP src port 53,123 - амплифаеры). Также иногда до нескольких млн в сек. SYN'ы приходят. Атаки как под копирку, что позволяет предположить, либо действуют одни и те же люди, либо используется одно и то же автоматизированное средство для организации ддос.
Как следует из тарифов, используете для кеша, а не в качестве основного раздела. это норм, хотя имхо все равно дороговато. Ну, пусть это будет вам рекламой :)
Sinaro: Я покупал в последнее время 800GB 8 штук.
Сейчас уже есть диски и побольше.
Я когда про 240/480Гб говорил, имел ввиду исключительно Intel. У других вендоров, бывает, больше, но с ними нужно экспериментировать. А вы что используете? Какая статистика по выработке/скоростям?
rustelekom: Ошибок действительно не видно. Вероятно, это кеш какой-то на стороне яндекса да гугля. Давно ли изменился айпи?
PS. Возможно, мажоры случайно блокируют и то и другое, тоже стоило бы уточнить.
Кеш вряд ли. гугловые и яндексовые днс-резолверы не игнорирют TTL, который у ТС вполне адекватен ситуации.
$ host -t SOA zdorovye-mam.ru
zdorovye-mam.ru has SOA record ns.majordomo.ru. support.majordomo.ru. 2004032900 3600 900 3600000 3600
Скорее всего, запросы блочатся на стороне хостера (если с момента переноса уже прошло несколько часов). Попробуйте обратиться в поддержку.
'[umka: ;13188745']Возьмём лучше IDE Сажаем на него десяток клиентов с вялыми сайтами. Берём SSD и сажаем на него 100500 клиентов с нагруженными сайтами. Сайты на IDE в данном случае будут работать шустрее. Я это имел в виду. На многих хостингах, с целью максимизации прибыли, каждый сервер забивается клиентами под завязку. Потом ставится следующий сервер и т.д. А когда клиенты на сервере, как кильки в банке, то нет разницы, на каком диске кряхтят их сайты, на IDE или на SSD :)
Если мы возьмем не мгновенную скорость и стабильность работы, а в течение заметного промежутка времени, получится, что пару раз в день на сервере с IDE-дисками один из вялых сайтов делает тяжелые запросы в БД и еще каждую ночь запускаются бекапы на несколько часов + поисковики приходят.
А еще из-за более медленного отклика диска дольше будет выполняться скрипт, который в свою очередь занимает некоторый объем оперативной памяти. То есть более стабильной работой это никак не назовешь.
Что касается SSD-дисков, на счастье клиентам хостинга, текущий объем твердотельных носителей не позволяет поселить туда 100500 пользователей, поскольку объем одного диска 240Гб, либо у тех, кто покупал в последнее время, 480Гб. (а кол-во iopsов в 1000-5000 раз больше).
Опять же, если взять экономику вопроса, 4x600Гб SAS в рейд10 стоит не меньше, чем 4x480Гб SSD в рейд5 (из расчета стоимости 1гб пространства).
В современных серверных системах производительность дисковой системы (особенно в iops) является самым узким местом. Кроме того, большая часть хостеров (я не говорю, что это невозможно) не умеет нормально приоритезировать/шейпить io. Тенденция по переходу на SSD или, если нужен большой объем дискового пространства, на SAS/SATA с кешом на SSD (flashcache и т.п.) достаточно устойчивая. Ну и мифы о том, что все SSD умирают через полгода также уходят в прошлое.
С учетом принятого закона о хранении личных данных не вижу смысла держать сайты за рубежом, чтобы потом обратно переносить в РФ.
Поэтому из этих двух - ihc
+ есть подозрения, что фоззи та же контора, что и макхост с евробайтом.
Фоззи не связан с макхостом и евробайтом, инфа 100% - есть хорошо знакомые люди там.
SYN на порт 80 ?
Чаще всего да. Но современные сервера даже без особых хитрых антиддосов при включенных син-куках приличные SYN-атаки держат без проблем. Либо не очень сложно допиливается свое решение на базе фреймворка NETMAP, но там надо немного пописАть.
Трафик с чего приходит ?
У нас атакуют постоянно клиентов с игровыми серверами. Причем атаки достаточно однообразные, которые особых проблем не доставляют: 5-15 Гбит/с (UDP fragmentation, UDP src port 53,123 - амплифаеры). Также иногда до нескольких млн в сек. SYN'ы приходят. Атаки как под копирку, что позволяет предположить, либо действуют одни и те же люди, либо используется одно и то же автоматизированное средство для организации ддос.
Да, реально.
Как следует из тарифов, используете для кеша, а не в качестве основного раздела. это норм, хотя имхо все равно дороговато. Ну, пусть это будет вам рекламой :)
Intel (DC S3700), они в работе около 8 месяцев, отказов нет.
Я их видел в магазинах еще в конце 2012 года.
Скорости очень хорошие.
Диски Intel DC S3700 800Gb стОят от 65тр за штуку.
Вы реально их используете в серверах массового хостинга vps? Это же расточительно. Даже на сайт зашел к вам тарифы посмотреть :)
Я покупал в последнее время 800GB 8 штук.
Сейчас уже есть диски и побольше.
Я когда про 240/480Гб говорил, имел ввиду исключительно Intel. У других вендоров, бывает, больше, но с ними нужно экспериментировать. А вы что используете? Какая статистика по выработке/скоростям?
Ошибок действительно не видно. Вероятно, это кеш какой-то на стороне яндекса да гугля. Давно ли изменился айпи?
PS. Возможно, мажоры случайно блокируют и то и другое, тоже стоило бы уточнить.
Кеш вряд ли. гугловые и яндексовые днс-резолверы не игнорирют TTL, который у ТС вполне адекватен ситуации.
$ host -t SOA zdorovye-mam.ru
zdorovye-mam.ru has SOA record ns.majordomo.ru. support.majordomo.ru. 2004032900 3600 900 3600000 3600
Скорее всего, запросы блочатся на стороне хостера (если с момента переноса уже прошло несколько часов). Попробуйте обратиться в поддержку.
;13188745']Возьмём лучше IDE
Сажаем на него десяток клиентов с вялыми сайтами. Берём SSD и сажаем на него 100500 клиентов с нагруженными сайтами. Сайты на IDE в данном случае будут работать шустрее.
Я это имел в виду. На многих хостингах, с целью максимизации прибыли, каждый сервер забивается клиентами под завязку. Потом ставится следующий сервер и т.д.
А когда клиенты на сервере, как кильки в банке, то нет разницы, на каком диске кряхтят их сайты, на IDE или на SSD :)
Если мы возьмем не мгновенную скорость и стабильность работы, а в течение заметного промежутка времени, получится, что пару раз в день на сервере с IDE-дисками один из вялых сайтов делает тяжелые запросы в БД и еще каждую ночь запускаются бекапы на несколько часов + поисковики приходят.
А еще из-за более медленного отклика диска дольше будет выполняться скрипт, который в свою очередь занимает некоторый объем оперативной памяти. То есть более стабильной работой это никак не назовешь.
Что касается SSD-дисков, на счастье клиентам хостинга, текущий объем твердотельных носителей не позволяет поселить туда 100500 пользователей, поскольку объем одного диска 240Гб, либо у тех, кто покупал в последнее время, 480Гб. (а кол-во iopsов в 1000-5000 раз больше).
Опять же, если взять экономику вопроса, 4x600Гб SAS в рейд10 стоит не меньше, чем 4x480Гб SSD в рейд5 (из расчета стоимости 1гб пространства).
Лучше запретить создавать свои темы для людей с кол-вом сообщений меньше X. А общую тему "подскажите, какой хостинг выбрать?" закрепить в топе :)
;13188583']Чем аргументируете? :)
В современных серверных системах производительность дисковой системы (особенно в iops) является самым узким местом. Кроме того, большая часть хостеров (я не говорю, что это невозможно) не умеет нормально приоритезировать/шейпить io. Тенденция по переходу на SSD или, если нужен большой объем дискового пространства, на SAS/SATA с кешом на SSD (flashcache и т.п.) достаточно устойчивая. Ну и мифы о том, что все SSD умирают через полгода также уходят в прошлое.