Коллеги,
1841 - фактически, мультисервисный SOHO-роутер (для малых офисов) с поддержкой VoIP, IPSec VPN. Его производительность настолько мала, что рекомендовать подобные решения сейчас просто вредно. По официальным (IMHO - несколько завышенным) данным, ISR 1841 выдает на роутинге аж 38 мбит/с и до 75к pps (см. дейташит). Это означает, что в случае современной минимальнейшей атаки эта железка мгновенно "уйдет в себя" и даже snmp-трап не сможет отослать. Кроме того, на борту у 1841 нет гигабитных портов - только пара 10/100, с такой производительностью гигабитные порты этой железке не нужны.
Будьте внимательны в своих предложениях :)
С уважением,
Дмитрий
Cisco Authorized Reseller since 1999 :) (сейчас уже нет - не продлевал статус последние два года).
Позвольте мне прокомментировать ситуацию.
Несколько часов назад один из наших партнеров сообщил, что время от времени он отмечает проблемы со связностью. Как оказалось, маршрутизатор (собственность нашего партнера) рвал физическое соединение на небольшое время, что приводило к регулярной перестройке BGP-сессий и, соответственно, пенализации (временном запрете на маршрутизацию).
Мы предоставили для замены собственный, резервный маршрутизатор, который был нами припасен для несколько другой задачи и был доступен на территории ДЦ - картина складывалась таким образом, что можно было предположить аппаратные неисправности. После замены оказалось, что проблема исчезла только на незначительное время. К счастью, после этого причина была найдена достаточно быстро - фактически, это была атака изнутри сети нашего клиента на его собственный роутер, что вызывало перегрузку CPU маршрутизатора.
В данный момент проблема совместными стараниями моих коллег и сотрудниками нашего партнера локализована, сеть нашего партнера работает в штатном режиме.
Кроме того, насколько мне известно, недоступность была у крайне небольшого количества серверов friendhosting.net. Поэтому не стоит преувеличивать масштабы произошедшего :)
ДЦ ИТЛ
MrKIM, характеристика "плохие" или "хорошие" - субъективна. Есть различные применения и нужно плясать от задачи.
У нас технологические хосты есть в нескольких странах и по объективным характеристикам украинское коннективити, мягко говоря, не хуже :)
p.s. Если желаете, опишите (в личку, чтобы не захламлять тему) Ваши наблюдения, но с техническими данными. Возможно, можно будет найти объяснение Вашим впечатленияем.
Это не соответствует действительности. Значительная часть транзита Россия-Европа идет через Украину (физически), что дает достаточно большую доступную емкость, возможность эксплуатировать "перекосы" трафика и так далее.
Стоимость полос невелика по сравнению с той же Россией (и это видно по ценам на выделенные полосы в ДЦ) и находится на уровне средних европейских хабов.
Так что уж с чем-чем, а с каналами в УА более чем удовлетворительно, как в Европу, так и в Россию.
Это очень тонкая грань, переход за которую приведет к резкому падению производительности. Соответственно, при массовой продаже услуг проще доабвить 1-2 ноды, нежели сидеть и мониторить загрузку с целью выжать лишние $10 с ноды.
Что касается CPU - как правило, на современных нодах (у нас, по крайней мере) загрузка процессора не доходит и до 25%, поэтому это не тонкое место. Вероятно, нам повезло - наши клиенты не майнят LiteCoin :)
Что касается оверселлинга памяти - да, но:
1) Это нужно специально включать. Причем память не недодается - просто она может оказаться в свопе вместо ОЗУ.
2) Изначально будет видна низкая производительность (i/o на ноде будет загружен свопом).
3) Вместе с тем, внутри контейнеров не будет дикой ситуации, когда память вроде как есть, но получить ее нельзя.
4) Совесть хостера никто не отменял. Я точно знаю, что есть такие, кто не оверселлят :)
Самый большой больной вопрос - одно ядро на всех. В результате переключение контекста может забирать слишком много ресурсов ядра - другими словами, накладные расходы на обслуживание большого кол-ва процессов могут при определенных условиях сравнимы с нагрузкой от самих процессов.
В случае с OpenVZ обычно происходит другое - возможность не дать ресурсы, так как нет их четкого выделения :)
Миграция в KVM, да и других системах давно уже есть и работает. Влияние "соседей" в случае с KVM/Xen/VmWare значительно ниже (см. о context switching).
Если коротко - берите KVM, такие VDS значительно более "честные" по ресурсам, нежели системы виртуализации на уровне ОС (OpenVZ, Jail и т.д.).
Я предполагаю, что этот адрес (91.222.136.250) ddos-ят, поэтому он в nullroute. На соседние адреса из этого-же диапазона адресов трафик их "мира" ходит нормально.
Спасибо за теплые слова, уверен в том, что Вам понравятся наши услуги.
Это далеко не универсальный рецепт. Подобное сработает только в том случае, если PHP исполняется в виде модуля apache. Многие используют FastCGI, где параметры PHP изменяются только в локальном php.ini.
ТС, прислушайтесь к рекомендациям yesRuslik. VDS будет лучшим и вполне недорогим решением вопроса. Не напрягайте сервера хостеров загрузками таких больших файлов :)
