А я и прохожу мимо. Первое собщение я прочитал достаточно внимательно, и понял что варианты SATAII не интересуют, и их не предлагать. Так я их и не предлагал. Я хотел намекнуть что вам.... нет, все таки тебе, т.к. уровень уважения сейчас ниже плинтуса...
для решения этой задачи нужно:
сначала сформировать условия задачи, с ЦИФРАМИ.
с цифрами о средней нагрузке на запись и чтение раздельно. В показателях iops и tps.
с цифрами о среднем размере блока или файла, если работа идет с файлами.
с цифрами о пиковых нагрузках, которые есть сейчас и на какой системе с каким iowait они перевариваются.
с требуемыми показателями надежности (как я заметил ты хотел взять ОДИН диск, без рейда?)
и требование ширины канала или латентности до какой то точки сразу озвучить.
Потом взять ЦИФРЫ с сайта производителя оборудования (sas & ssd дисков) и посчитать в какой конфигурации
(1 диск, или N дисков организованых в raid1, raid0, raid10) это оборудование потянет эту пиковую нагрузку.
Поделив ЦИФРЫ на ЦИФРЫ.
Потом посчитать столько такая дисковая система в разных вариантах будет стоить в аренде.
Потом выбрать самый дешевый вариант и поинтересоваться у хостеров кто такое уже имеет или может построить.
====
Если бы ты появился на форуме допустим автоперевозчиков с запросом перевезти дохрена груза, при этом "машины на метане не предлагать, только дизель, потому что он быстрее и надежнее", и без холиваров что лучше. И потом бы начал отметать предложенные варианты, потому что фура недостаточно быстрая, цвет не тот, и добавлять в коменты "тут любят только языком чесать, а не предлагать услуги" думаю вам бы прямолинейные водилы четче бы все пояснили, И уверен что модератор бы их еще и поддержал.
А имел в виду стоимость контроллера поделенную на количество портов в нем.
А есть это внешний агрегат с поддержкой raid60 или hba без мозгов - не суть важно.
Тут вопрос также не о том кто такой средний рейд, и чем хуже програмный рейд 10 чем аппаратный.
ТС не хочет холивара, он хочет найти кого то кто зачем то заимел мощную дисковую систему, и не знает чем ее
озадачить. А тех кто ее озадачили берет в кавычки, "типа лохи".
Большинство вменяемых хостеров сначала бы поинтересовалось какое io и в каких единицах вы имеете.
А потом начали бы вероятно уточнять вопрос:
раздельно нагрузка на чтение и на запись, т.к. если вам 10 гигов или меньше хватает с головой, то
налиие 8 гигов оперативки, из которых 7 уйдет на дисковый кеш чтения, уберут нагрузку на чтение почти
в ноль.
специфика нагрузки на запись -
raw запись (мега растущий лог) - вам вполне пойдут и sata диски, линейные характеристики у них неплохи.
рандом блоками по 512 байт - 4КБ - да, полезен sas 15K
блоки 16-64КБ - пожалуй лучше SSD себя покажет.
А то как вы посчитали стоимость диска - да, неплохо. Только диск не висит в воздухе. Нужно еще посчитать стоимость sas-порта, стоимость слота в кузове, и какой то процент от стоимости матери, проца... даже про стоимость порта в коммутаторе тоже забывать не стоит.
Если у вас есть б-м тяжелая задача, так опишите ее, в цифрах, потом выслушайте новые запросы, какие еще цифры нужны для грамотного решения задачи, потом пронаблюдайте холивар, сделайте из него выводы и т.д.
А если вы сами знаете что вам нужно, то не компостируйте уважаемому all-у мозг, и google вам в помощь в поисках VPS на sas.
sataII - Это интерфейс. Точка.
Он одинаков и для твердотельных дисков, и для "говновеников" rpm 7200. И для энтерпрайз веников rpm7200 тоже (hitachi ultrastar или wd black это говновеник по вашему?)
Поток с процессом я не сравнивал. И в мыслях не имел. Репликация идет в 1 поток на 1 процесс. Если записей идет слишком (настолько) много что слейв отстает от мастера и не может его догнать значит либо между ними слишком медленный канал (настолько что данные бинлога не успевают передаться в один поток) тогда запускаем несколько процессов Mysql (по одному на одну базу например) и получаем несколько потоков репликации (threads) и несколько потоков при передаче (tcp connections). Либо производительность слейва настолько отличается от мастера, что он не успевает обрабатывать все операции insert+update (это проблемы не с mysql и не с репликацией, а с головой или деньгами)
Падение с поломкой целостности данных возможно в 2-х случаях - либо повреждение данных при передаче бинлога по сети (а при этом и обычная репликация сталобыть падает с ровно такой же вероятностью/2) либо при совпадении данных индексов по автоинкременту, а это я упомянул. И как это можно пытаться обходить тоже упомянул.
В общем слив засчитан.
hvosting добавил 10.07.2011 в 00:17
А вот с вами я как раз согласен. Действительно падает. Если в течение б-м продолжительного времени между серверами отсутствовала связь, и в каждый из них за это время успела прийти кипа запросов с использованием автоинкремента. Именно поэтому выше встречается слово "пытаться". Но ведь мы обсуждаем не промышленное отказоустойчивое решение для hiload систем, а сферический велосипед с квадратными колесами в вакууме для временно малобюджетной защиты мелких коробочных сайтов от DDoS?
Вы путаете 7200 rpm и sata2 (ssd диски тоже sata, нет?)
Вы путаете процесс и поток. (можно запустить несколько процессов mysql на одном сервере, нет?)
Полносвязная репликация подразумевает что каждый ноявляется мастером и слейвом одновременно.
для 2-х машин работает точно, дописали ли для большего - не уверен, в планах было.
Речь вообще не об отказоустойчивости, а о ддос атаке (или я что то пропустил?) Кто сказал что какой то из серверов mysql обязан находиться в атакуемой точке/иметь отношение к атаке?
Какие то из CMS (популярных) точно заточены под работу в режиме master-slave, видел в настройках. Но пруфлинки не дам, ибо не помню, и искать лениво.
А в чем проблема работать из "каропки" с ndb? Между репликацией и кластером есть большая разница.
Если кластерные FS такая универсальная "пуля от всех болезней" почему на них давно не перешли все повально?
Очень регурялная синхронизация ФС по расписанию при помощи rsync почти решает вопрос аватаров с совпадающим названием.
Но при этом основательно убъет производительность дисковой системы.
А если при заливке делать картинке случайное имя, или солить его таймстампом - вопрос будет снят автоматически.
Для коробочных CMS тоже можно решить вопрос, в общем виде.
Могу на спор (порядка 20$) объяснить на пальцах как можно организовать синхронизацию
в практически реальном времени (задержка синка порядка 1 секунды) с примерением rsync и без применения кластерных ФС.
Синхронизация баз данных - вообще крайне просто решается. Репликация по полносвязной схеме. Но есть очень большой подводный камень, просто глыба - autoincrement.
При 2-3 серверах его еще можно кое как решить путем указания разного шага на серверах. При большем количестве - это уже не метод.
Второе решение - отправка всех запросов на запись в единый мастер, а чтение - из локальных слейвах.
Но тут требуется либо работа напильником над CMS, либо достаточно стремный софт.
Но никто здесь экономически не поднял вопрос о том, что DDoS на VPS подразумевает пролетание трафика через 1 реальный интерфейс, и 2 виртуальных. Это утраивает накладные расходы на процессор, irq и т.д.
Строить такую систему на распределенных атомах - сложно и не рационально. Есть более рациональные варианты.
На VPS-ах - просто бред.
rsync нормально справится с разруливанием таких картинок и разольет по всем серверам наиболее свежую (позже всего модифицировавшуюся ) каритнку.
Но сама по себе идея использовать несколько дешевых впс на мой взгляд не имеет смысла.
Тут ничего странного. Они сейчас спят, а секундой раньше или еще через секунду будут работать.
И по ним видно какой то расход cputime и какой то расход оперативки. Но не видно когда они были запущены - 30 секунд назад или час назад, а это достаточно важно.
Каким образом люди вообще впихивают в 128 метров
apache + php, mysql , ispmgr light - я удивляюсь.
На вашем скриншоте от хостера вероятно изображена выдержка из ps на тот момент.
т.е. на cервере было запущено 16 потомков апача, с расходом оперативки порядка 128 метров.
это только на apache + php.
Текущий хостер в каких то единицах нагрузку выдать может? В минутах процессорного времени, или более 5% в течение Х минут подряд. Данных о перегрузке по сути нет.
Так вы эту систему предлагаете реализовывать обычным пользователям, а не строите или обсуждаете собственное анти ддос решение?
