Экономные делают LVS или Nginx (но этот не все умеет балансить), чуть более извращенные ставят к примеру HAProxy, более извращенные и богатые ставят Cisco ASA и ему подобные
NFS поднят через отдельный гигабитный маршрутизатор, сервера в него светят «небоевыми» сетевухами (то есть NFS на одном интерфейсе, а http траф на другом, да и через другой маршрутизатор). Свичи простецкие Cisco 2970 или подобные. В схеме с СХД каким-то другим способом и не «пошарить» общий том на фронты и бекэнды
Минус-не-минус, но mysql proxy можн смело почикать, для минимизации затрат. Держать две машины под прокси — черезчур. Можно забалансить другими методами (да хоть Linux Virtual Machine, если хочется в приложении не париться доступом к разным ip).
Еще, с моей точки зрения, минус — локальные скрипты на каждом бекенде. В моем случае весь проект, включая скрипты, лежит на системе хранения, которая «расшарена» на все web-сервера (и фронт и бекэнды), соответственно одинаковые настройки апачей и nginx отдает всю статику сам, скрипты проксирует на апачи. Архитектура приложений разрабатывается таким образом, что никакие скрипты не могут писать в один и тот-же файл (логично! нафига нам геморой с локами, хотя это тоже решабельно). Ну и забываем о проблемах синхронизации заодно. Надежность систем хранения обеспечивается другими методами (взрослые ли СХД, DRBD и т.п.)
В нашей схеме потеря любого backend вообще никак не сказывается на работоспособности, в этом случае или при пиковой нагрузке мы можем еще и staging сервер зацепить в качестве backend'а. Он является таким же backend'ом, только доступен «снаружи» мимо nginx и на нем тестируются обновления (короче это либо дев машина или выделенный в ферме сервер на котором делаются аццкие эксперименты по вкатыванию обновлений, сборки свежего софта и обкатки конфигурации).
Для совсем небольших проектов, где не требуется HA, но хочется определенного запаса производительности и масштабируемости в будущем у нас работает схема (очень экономная):
1. Один nginx frontend + storage controller + nfs server
2. Один Apache backend + все cron задачи
3. MySQL Master
4. MySQL Slave + backup
Все это конечно же на «брендовых» серверах с гарантией на замену хотя бы NBD. Мы используем HP Proliant DL360/DL380. Это страховка на случай поломок.
стоимость решения вы может и минимизируете, но мы же HA систему строим, не? Практика показала — на HA (и конечно это HighLoad, иначе зачем нам HA) выгоднее увеличить стоимость первоначального решения — ибо стоимость простоя и стоимость восстановления или масштабирования в будущем получится гораздо выше.
Мы пока остановились на примерно такой схеме для «небольших» проектов: balancer -> 2 nginx frontend -> 2+ apache backend + staging backend -> DB Master + DB Slave -> Backup. В этой схеме можно немного заэкономить и совместить балансинг и фронт в одной машине. Учитывая то, что все сервера одинаковой конфигурации — даже в случае поломки можно быстро переконфигурить любую машину фермы на выполнение другой роли. В нашей схеме правда есть еще storage controller — сервер(ы) держащие SAN-NAS-DAS стораджи и раздающие их на ферму.
Схема достаточно распростаненная, можно сказать стандартная даже. Есть конечно некоторые хитрости — например вынос тяжелых SQL работ не требующих записи в базу на slave (например поиск по форуму)
>Дело в том, что mysql нагружает диски, а апач нагружает процессор и они довольно сносно уживаются на одном сервере.
Когда научитесь отдавать с Апача что-нибудь мелкофайловое с потоком мегабит этак в 300 — поймете, что апач тоже умеет некисло нагружать диск и в итоге оно заткнется (я знаю, что можно отдавать с nginx, но не всегда это возможно). Поэтому в случае HA проектов лучше таки разделить web & db сервера.
Макс, я как бы лично ответил, но многим думаю будет интересно.
Так вот. Количество файлов в директории достаточно серьезно влияет на производительность получения их списка, поэтому лучше хранить в виде /1/1/1/1/1111.jpg. А дело в том, что «This is caused by readdir() returning filenames in a hash-sorted order, so that reads from the inode table would be done in a random order». Самое забавное, что при прямом поиске по имени — падения производительности не происходит, а вот при удалении файлов из такой большой папки, особенно групповом — будет очень плохо
md5 заголовков хранятся в базе рядом с ними, поэтому select title where md5_tile='md5hash' :-)
Хранить решил именно потому, что оно втыкается в шаблон документов, чтоб лишнюю математику при генерации не городить, обновляется только через админку.
Не очень оптимально, но работоспособно. Цели highload'а не было.
Посетители и так их не генерят, оно втыкается «статичной» картинкой с именем из md5 хеша, скрипт просто находит в DB соответствие заголовку и генерит текст первый раз по нему, потом она так и остается на диске. То есть алгоритм приметрно такой: Есть запись в базе с заголовком, в HTML генерится ссылка на картинку имя которой представляет из себя md5 от заголовка, при запросе картинки скрипт лезет в базу, и только при совпадении — берет тектс из нее, генерит на диск картинку, выпуливает X-Accel-Redirect, если картинка есть — ее nginx отдает сам. Как то так. В принципе возможен DoS, но там полтора инвалида в месяц посетителей
я в одном проекте делал генератор заголовков в картинках (долбанный фирменный шрифт заказчика). Очень похоже было, заголовочек генерился если файлика нет, если есть — выпуливался в nginx через X-Accel-Redirect.
>Я привык к дебиану и арчу. Вы так говорите как будто его надо гаечным ключом на 40 градусном морозе подключать. Всего подключения — одна строчка в конфиге, которая по умолчанию уже есть в обоих названных мной дистрибутивах.
В Sarge ввиду старого open-ssh нет Chroot по sftp и соответственно sftp-subsystem родная бесполезна. Приходилось юзать MySecureShell.
что значит нет? А топовый 27" на Core i7 отменили?
2.93GHz Quad-Core Intel Core i7
8GB 1333MHz DDR3 SDRAM — 2x4GB
2TB Serial ATA Drive
8x double-layer SuperDrive
ATI Radeon HD 5750 1GB GDDR5 SDRAM
5750 конечно не 5980, но тут уже издержки компактности и тепловыделения
У первых спецификаций TIFF было только LZW (во времена Aldus, от которой все досталось Adobe), а так же тег NewSubfileType давал делать только «страницы» внутри TIFF, хранение слоев приделала уже Adobe, им проще — они владельцы спецификации, могут расширять теги как угодно.
Такой же формат (за исключением хидера и в точном соответствии с первоначальными спецификациями и без сжатия) используется в формате Scitex CT
Я хоть и работаю сейчас на MX Revolution/VX Revolution (десктоп и ноут соответственно), но у меня есть до сих пор вполне рабочая ШАРИКОВАЯ мыша M-BA47 (первый аццкий «утюг» от Logitech). Ей уж лет так 10, причем первый лет пять она использовалась в ретуши по 12 часов в сутки. Вот такая www.ixbt.com/peripheral/logitech-m-ba47.shtml. Сейчас достаю из ящика раз в месяц при установке очередного сервера.
Еще, с моей точки зрения, минус — локальные скрипты на каждом бекенде. В моем случае весь проект, включая скрипты, лежит на системе хранения, которая «расшарена» на все web-сервера (и фронт и бекэнды), соответственно одинаковые настройки апачей и nginx отдает всю статику сам, скрипты проксирует на апачи. Архитектура приложений разрабатывается таким образом, что никакие скрипты не могут писать в один и тот-же файл (логично! нафига нам геморой с локами, хотя это тоже решабельно). Ну и забываем о проблемах синхронизации заодно. Надежность систем хранения обеспечивается другими методами (взрослые ли СХД, DRBD и т.п.)
В нашей схеме потеря любого backend вообще никак не сказывается на работоспособности, в этом случае или при пиковой нагрузке мы можем еще и staging сервер зацепить в качестве backend'а. Он является таким же backend'ом, только доступен «снаружи» мимо nginx и на нем тестируются обновления (короче это либо дев машина или выделенный в ферме сервер на котором делаются аццкие эксперименты по вкатыванию обновлений, сборки свежего софта и обкатки конфигурации).
Для совсем небольших проектов, где не требуется HA, но хочется определенного запаса производительности и масштабируемости в будущем у нас работает схема (очень экономная):
1. Один nginx frontend + storage controller + nfs server
2. Один Apache backend + все cron задачи
3. MySQL Master
4. MySQL Slave + backup
Все это конечно же на «брендовых» серверах с гарантией на замену хотя бы NBD. Мы используем HP Proliant DL360/DL380. Это страховка на случай поломок.
Мы пока остановились на примерно такой схеме для «небольших» проектов: balancer -> 2 nginx frontend -> 2+ apache backend + staging backend -> DB Master + DB Slave -> Backup. В этой схеме можно немного заэкономить и совместить балансинг и фронт в одной машине. Учитывая то, что все сервера одинаковой конфигурации — даже в случае поломки можно быстро переконфигурить любую машину фермы на выполнение другой роли. В нашей схеме правда есть еще storage controller — сервер(ы) держащие SAN-NAS-DAS стораджи и раздающие их на ферму.
Схема достаточно распростаненная, можно сказать стандартная даже. Есть конечно некоторые хитрости — например вынос тяжелых SQL работ не требующих записи в базу на slave (например поиск по форуму)
У меня вон они стоят MSA2000fc G1 + пара полок к ней. Правда дисками до конца не заполнены.
Когда научитесь отдавать с Апача что-нибудь мелкофайловое с потоком мегабит этак в 300 — поймете, что апач тоже умеет некисло нагружать диск и в итоге оно заткнется (я знаю, что можно отдавать с nginx, но не всегда это возможно). Поэтому в случае HA проектов лучше таки разделить web & db сервера.
Так вот. Количество файлов в директории достаточно серьезно влияет на производительность получения их списка, поэтому лучше хранить в виде /1/1/1/1/1111.jpg. А дело в том, что «This is caused by readdir() returning filenames in a hash-sorted order, so that reads from the inode table would be done in a random order». Самое забавное, что при прямом поиске по имени — падения производительности не происходит, а вот при удалении файлов из такой большой папки, особенно групповом — будет очень плохо
Хранить решил именно потому, что оно втыкается в шаблон документов, чтоб лишнюю математику при генерации не городить, обновляется только через админку.
Не очень оптимально, но работоспособно. Цели highload'а не было.
В Sarge ввиду старого open-ssh нет Chroot по sftp и соответственно sftp-subsystem родная бесполезна. Приходилось юзать MySecureShell.
2.93GHz Quad-Core Intel Core i7
8GB 1333MHz DDR3 SDRAM — 2x4GB
2TB Serial ATA Drive
8x double-layer SuperDrive
ATI Radeon HD 5750 1GB GDDR5 SDRAM
5750 конечно не 5980, но тут уже издержки компактности и тепловыделения
Такой же формат (за исключением хидера и в точном соответствии с первоначальными спецификациями и без сжатия) используется в формате Scitex CT