foxi: так прокси (тот же nginx) не найдя картинки у себя - будет долбить первый сервер, создавая на нем нагрузку...
Я же не сказал что в полной мере картинки переезжают на второй сервер, этого в моей схеме не было.... Смотрите, запрос приходит на SQUID/NGINX, если там в кеше есть картинка она отдается из памяти, и к бекенд серверу вообще обращения за ней не будет, а если её нет конечно то она будет запрошена у бекенда, именно в этом и схема, настраиваете кеш так что бы он захватывал необходимое количество нужных вам картинок, там очень много возможностей с точки зрения кеширования (это про squid, не знаю как nginx).... Но из памяти отдача в кучу раз быстрее чем с винта, я думаю что реализовав такую схему БЕЗ изменения кода, вы уже получите выигрыш в производительности, хотя бы потому что новая загруженная картинка через 5 минут уже будет отдаваться не с винта а с кеша (уменьшиться количество обращений в диск на бекенд сервере)
myhand: Без указания специфики этого "опыта" и конкретно в Ваших устах - это для меня звучит еще менее интересно, чем заявление Андрейки.
Думаю, можно и голубиную почту. Нужно-ли - вот вопрос.
Этот "оптимальный вариант" разобрали по косточкам выше, парой постов. Неужели сложно вначале что-то потрудиться почитать, а только потом нести свою лабуду?
Вы хам как минимум, это я вам лично заявляю!
Что касается оптимального варианта, почитайте сами и скажите мне в чем проблема, пусть 1 сервер который есть сейчас обрабатывает все картинки с точки зрения GD или чем там они на превью режуться у ТС-а, а прокси прозрачное само будет решать (от настроек) что брать из кеша а что брать у парентов.
Тс, не слушайте этого хама, Андрейка вполне логичен, для вашей схемы NFS это зло, а точнее избыток, даже если будет работать........
myhand, а я вот тоже поддержу Андрейку, с NFS имел только негативный опыт, хотя по правде говоря видел и работающие решения на NFS, но нужна ли ему реально FS вообще сетевая? rsync -ом нельзя гонять картинки на второй сервер? Думаю можно..... А еще можно путем nginx или SQUID организовать прокси , там пофик что будет происходить все будет обработано на одном сервере а вот раздаваться будет по мере наполнения кеша.... по моему самый оптимальный вариант.
Риторический вопрос: может советы давать не надо, предварительно не "ознакомившись" с, извините, элементарной информацией?
Я вот ссылку вашу почитал, что-то не пойму, вы это говорите потому что чилды поумирают? Это вся разница?
Может привычка и пагубная, но откуда-то она взялась, kill -1 отправляю для перечитываний. Хотя в случае апачей и прочего не вижу вообще смысла беспокоить дескриптор лог файла при ротации, можно файл обнулить и дело с концом... по этому у меня ни -1 ни USR1 не выполняется в принципе, а рекомендовал , то что я рекомендовал, именно по тем соображениям, что уже сталкивался с аналогичной историей, когда после ротации прекращались писать логи. И подчеркиваю еще раз БЫЛ и я думаю ЕСТЬ флаг в настройках syslogd который как раз таки отвечает за отправку этого самого сигнала, может там конечно и не -1 , а USR1 как вы говорите, но я ответил вполне по теме.
LineHost: Странные посчёты и по моему далеки от реальности.
Не забегайте раньше времени вперед :D Обсудим :D
LineHost:
1. Для начала бэкап надо создать. Если это архив, то на 100 гб реального хостинга на мощном сервере с RAID10 (сервере, не на десктопе типа i920, которые пользуется спросом у хостёров) уйдёт около часа, если нет пользователей с огромным количеством мелких файлов на акаунте. Если не повезло, то 100 гб может создаватся 5-6 часов или даже больше. Если надо лимитировать использование ресурсов на копирование, чтобы не тормозить сервер, времени понадобится ещё больше.
Тут и спорить нет смысла, ни кто не говорит что хаотичный контент запрыгнет в самый сжатый архив за пару секунд :D У меня процесс длиться монотонно, отжираем мало, по времени идет долго, какраз около 6 часов а то и больше наверное, но в результате я имею файлы :d они же мегабайты и они так важны для клиента. Мне не жалко потратить 6 часов времени что бы потом в случае чего у меня была копия информации ))) тем более что ждать то не надо, оно по крону как-то само последние пару лет работает :d
LineHost:
2. 100 ГБ надо скинуть на удаленный сервер. На 100 мбпс сети, если не жалко отдать практически весь канал на резервное копирование, за час можно слить около 36 ГБ. На 100 ГБ грубо уйдёт три часа. Если сервер на который сливается копии способен принять весь трафик на полной скорости, в это время сайты клиентов будут тормозить достаточно сильно. В реальности на резервный сервер в одно и тоже время сливается с нескольких серверов, по этому канал рабочего сервера забит меньше, но весь процес длится дольше.
Вы главное не забывайте о параллельности процесса, и о том, что бекапов то много и они разные, или вы думаете мы сперва собираем всех хоумдиры в тарболы, потому пакуем их в один большой тарбол и потом отправляем одним куском ... нет, они заливаются в момент создания, соответственно избыточное время на перенос может появиться только при паковании и переносе последнего клиента, а остальное время проходит параллельно упаковке и отправке по-юзерно на бекап сервер. А если 1 Gb/s ?
LineHost:
В неблагополучных условиях такая схема резервирования станет тормозом и фактихески сервер будет большую часть времени перегружен, а клиенты недовольны.
То есть вы таки верите что в данной схеме они могут быть благополучны? Это приятно :D
LineHost:
Также такой прогон трафика скажем с одного датацентра на другой обойдётся достаточно дорого, так как всё таки реальные 3 ТБ в месяц. По этому на практике чаще всего бекапы делается на тот же диск который на самом сервере и чаще всего даже не RAID1.
Если лить из ДЦ в ДЦ через кучу лиинй - да будет сложно, но какие проблемы взять в том же ДЦ сервер для бекапа, или в каждом ДЦ где у вас сервера взять по серверу? Только финансы.... А так схема вполне живет успешно и долгое время, главное не стоит надеяться на то , что в 1 бекап сервер можно всунуть больше чем он может :D Тогда условия будут не благоприятные и бесспорно всему пипец.....
faedrus: Romka_Kharkov, читаю ваши посты и не совсем понимаю. Вы считаете что хостер не обязан заботиться о безопасности своих серверов и не обязан делать бекапы?
Не, вы что, как вы могли такое подумать после того что я написал выше, у меня даже два сервера для бекапов одного и того же пучка серверов, я просто хочу подчеркнуть тот момент, что петициями на форуме о том, что хостер был должен.......... делу не помочь, вы сидите без контента, без сайта, без заработка, без...., без...... , без...... а могли бы просто в целях собственной безопасности сделать хотя бы 1 раз в неделю бекап себе на ПК и писать уже не "помогите, спасите, хостер верни бекап", а "срочно ищу хостинг".
(Адресую в ваш адрес, так как вы задали вопрос, ничего личного естественно :D)
Вот еще что добавлю:
Одно дело если бы такого рода поступки хостера можно было бы легко юридически наказать, то поверьте, бекап был бы у всех.... остальные бы покинули рынок естественным путем :D
Но тут вот вопрос в том, что выбирая хостинг человек может даже не представлять, что у хостера 1 бекап который ротируется в тот же день... это просто смешно.... если знать об этом ... выбор бы пал в другую сторону к примеру... (имею ввиду к другому поставщику услуги).... по этому обезопасить себя самому - не это ли красота полета, а хостер если потеряет контент то это последний кто сможет вам помочь в таком случае :D разве что в виде компенсации материальной если будет судом это установлено..... вот в чем логика моя.... А хостеры ответственные я вас уверяю делают бекапы и скорее всего похлеще чем я тут со своими двумя запасными копиями :D
Я че-то не пойму вам еще в схеме защита от ддоса нужна?
А если ваш 1 сервер досят типа все в порядке? ничего не падает?
так прокси (тот же nginx) не найдя картинки у себя - будет долбить первый сервер, создавая на нем нагрузку...
Я же не сказал что в полной мере картинки переезжают на второй сервер, этого в моей схеме не было.... Смотрите, запрос приходит на SQUID/NGINX, если там в кеше есть картинка она отдается из памяти, и к бекенд серверу вообще обращения за ней не будет, а если её нет конечно то она будет запрошена у бекенда, именно в этом и схема, настраиваете кеш так что бы он захватывал необходимое количество нужных вам картинок, там очень много возможностей с точки зрения кеширования (это про squid, не знаю как nginx).... Но из памяти отдача в кучу раз быстрее чем с винта, я думаю что реализовав такую схему БЕЗ изменения кода, вы уже получите выигрыш в производительности, хотя бы потому что новая загруженная картинка через 5 минут уже будет отдаваться не с винта а с кеша (уменьшиться количество обращений в диск на бекенд сервере)
Без указания специфики этого "опыта" и конкретно в Ваших устах - это для меня звучит еще менее интересно, чем заявление Андрейки.
Думаю, можно и голубиную почту. Нужно-ли - вот вопрос.
Этот "оптимальный вариант" разобрали по косточкам выше, парой постов. Неужели сложно вначале что-то потрудиться почитать, а только потом нести свою лабуду?
Вы хам как минимум, это я вам лично заявляю!
Что касается оптимального варианта, почитайте сами и скажите мне в чем проблема, пусть 1 сервер который есть сейчас обрабатывает все картинки с точки зрения GD или чем там они на превью режуться у ТС-а, а прокси прозрачное само будет решать (от настроек) что брать из кеша а что брать у парентов.
Тс, не слушайте этого хама, Андрейка вполне логичен, для вашей схемы NFS это зло, а точнее избыток, даже если будет работать........
myhand, а я вот тоже поддержу Андрейку, с NFS имел только негативный опыт, хотя по правде говоря видел и работающие решения на NFS, но нужна ли ему реально FS вообще сетевая? rsync -ом нельзя гонять картинки на второй сервер? Думаю можно..... А еще можно путем nginx или SQUID организовать прокси , там пофик что будет происходить все будет обработано на одном сервере а вот раздаваться будет по мере наполнения кеша.... по моему самый оптимальный вариант.
А ничего что ТС про Россию писал? Или это всем пофигу?
Читайте внимательно, будет вам счастье:
Цитирую:
по мере поступления предложений может уточню требования
ТС, могу предложить в Канаде реселинг на cPanel, обращайтесь, на сайте цен нет, так как прямо реселингом не занимаемся, но могут быть и исключения.
http://httpd.apache.org/docs/2.2/en/stopping.html
Риторический вопрос: может советы давать не надо, предварительно не "ознакомившись" с, извините, элементарной информацией?
Я вот ссылку вашу почитал, что-то не пойму, вы это говорите потому что чилды поумирают? Это вся разница?
Может привычка и пагубная, но откуда-то она взялась, kill -1 отправляю для перечитываний. Хотя в случае апачей и прочего не вижу вообще смысла беспокоить дескриптор лог файла при ротации, можно файл обнулить и дело с концом... по этому у меня ни -1 ни USR1 не выполняется в принципе, а рекомендовал , то что я рекомендовал, именно по тем соображениям, что уже сталкивался с аналогичной историей, когда после ротации прекращались писать логи. И подчеркиваю еще раз БЫЛ и я думаю ЕСТЬ флаг в настройках syslogd который как раз таки отвечает за отправку этого самого сигнала, может там конечно и не -1 , а USR1 как вы говорите, но я ответил вполне по теме.
Все подробно и полно описано в документации, Вам указать туда дорогу?
Давайте линк, обязательно ознакомлюсь.
Странные посчёты и по моему далеки от реальности.
Не забегайте раньше времени вперед :D Обсудим :D
1. Для начала бэкап надо создать. Если это архив, то на 100 гб реального хостинга на мощном сервере с RAID10 (сервере, не на десктопе типа i920, которые пользуется спросом у хостёров) уйдёт около часа, если нет пользователей с огромным количеством мелких файлов на акаунте. Если не повезло, то 100 гб может создаватся 5-6 часов или даже больше. Если надо лимитировать использование ресурсов на копирование, чтобы не тормозить сервер, времени понадобится ещё больше.
Тут и спорить нет смысла, ни кто не говорит что хаотичный контент запрыгнет в самый сжатый архив за пару секунд :D У меня процесс длиться монотонно, отжираем мало, по времени идет долго, какраз около 6 часов а то и больше наверное, но в результате я имею файлы :d они же мегабайты и они так важны для клиента. Мне не жалко потратить 6 часов времени что бы потом в случае чего у меня была копия информации ))) тем более что ждать то не надо, оно по крону как-то само последние пару лет работает :d
2. 100 ГБ надо скинуть на удаленный сервер. На 100 мбпс сети, если не жалко отдать практически весь канал на резервное копирование, за час можно слить около 36 ГБ. На 100 ГБ грубо уйдёт три часа. Если сервер на который сливается копии способен принять весь трафик на полной скорости, в это время сайты клиентов будут тормозить достаточно сильно. В реальности на резервный сервер в одно и тоже время сливается с нескольких серверов, по этому канал рабочего сервера забит меньше, но весь процес длится дольше.
Вы главное не забывайте о параллельности процесса, и о том, что бекапов то много и они разные, или вы думаете мы сперва собираем всех хоумдиры в тарболы, потому пакуем их в один большой тарбол и потом отправляем одним куском ... нет, они заливаются в момент создания, соответственно избыточное время на перенос может появиться только при паковании и переносе последнего клиента, а остальное время проходит параллельно упаковке и отправке по-юзерно на бекап сервер. А если 1 Gb/s ?
В неблагополучных условиях такая схема резервирования станет тормозом и фактихески сервер будет большую часть времени перегружен, а клиенты недовольны.
То есть вы таки верите что в данной схеме они могут быть благополучны? Это приятно :D
Также такой прогон трафика скажем с одного датацентра на другой обойдётся достаточно дорого, так как всё таки реальные 3 ТБ в месяц. По этому на практике чаще всего бекапы делается на тот же диск который на самом сервере и чаще всего даже не RAID1.
Если лить из ДЦ в ДЦ через кучу лиинй - да будет сложно, но какие проблемы взять в том же ДЦ сервер для бекапа, или в каждом ДЦ где у вас сервера взять по серверу? Только финансы.... А так схема вполне живет успешно и долгое время, главное не стоит надеяться на то , что в 1 бекап сервер можно всунуть больше чем он может :D Тогда условия будут не благоприятные и бесспорно всему пипец.....
Romka_Kharkov, читаю ваши посты и не совсем понимаю. Вы считаете что хостер не обязан заботиться о безопасности своих серверов и не обязан делать бекапы?
Не, вы что, как вы могли такое подумать после того что я написал выше, у меня даже два сервера для бекапов одного и того же пучка серверов, я просто хочу подчеркнуть тот момент, что петициями на форуме о том, что хостер был должен.......... делу не помочь, вы сидите без контента, без сайта, без заработка, без...., без...... , без...... а могли бы просто в целях собственной безопасности сделать хотя бы 1 раз в неделю бекап себе на ПК и писать уже не "помогите, спасите, хостер верни бекап", а "срочно ищу хостинг".
(Адресую в ваш адрес, так как вы задали вопрос, ничего личного естественно :D)
Вот еще что добавлю:
Одно дело если бы такого рода поступки хостера можно было бы легко юридически наказать, то поверьте, бекап был бы у всех.... остальные бы покинули рынок естественным путем :D
Но тут вот вопрос в том, что выбирая хостинг человек может даже не представлять, что у хостера 1 бекап который ротируется в тот же день... это просто смешно.... если знать об этом ... выбор бы пал в другую сторону к примеру... (имею ввиду к другому поставщику услуги).... по этому обезопасить себя самому - не это ли красота полета, а хостер если потеряет контент то это последний кто сможет вам помочь в таком случае :D разве что в виде компенсации материальной если будет судом это установлено..... вот в чем логика моя.... А хостеры ответственные я вас уверяю делают бекапы и скорее всего похлеще чем я тут со своими двумя запасными копиями :D