Romka_Kharkov

На Украине есть еще множество валют которые без проблемно циркулируют внутри сети. :) Распространены WebMoney, куча Российских платежных интернет систем, зарубежные.

Почитайте, гривна это не панацея при покупке Хостинга в UA :)

Если рассмотреть такой вариант то конечно же.... может быть что угодно, завтра выяснится что у ТС-а 100 посещений в час и на самом деле стоит битая планка памяти... :))) Нет отправной точки, что гадать то...

P.S: Вы наверное верите в то, что сервер без особого напряга будет отдавать и 90Mb/s картинок? Лишь бы канал позволил?;)

Я четко помню отлупы Хостмастера когда еще mail templates туда слать надо было для регистрации , когда я забывал добавить домен на те DNS которые в форме указал, соответственно была проверка, я понимаю что сейчас все работает по протоколу, для регистрации и смены данных , но я не знаю как это в .UA устроено сейчас... давно не обращался :)

Вы посмотрите на цифры которые приводит ТС :) 2.5k коннектов в секунду к 62 GB фото архиву ;)

Я уже выше допускал ситуацию когда ТС придет к нагрузке.. и будет оно на SAS cтоять все, а так он может добавлять в ферму сервера в зависимости от нагрузки, рекламу закупил, серверов добавил, открутил - убрал... или включать в ферму разношерстные сервера любых комплектаций... такое решение может масштабироваться от 2.5k в секунду до 2.5 mln в секунду если это будет затребовано. При условии что ТС использовал уже 64 GB , а запасся 1 TRB , то очень скоро темпы потребления трафика возрастут :) Мне кажется что RAID тут не покатит. Любой рейд на сколько я понимаю будет медленней нежели винт сам по себе, так как надо будет производить доп. расчеты с данными, иногда интереснее использовать 2-3-4 сервера в ферме но с 1м винтом на каждом...

Вы или сообщения мои вообще игнорируете или частично не знаю, я уже трижды описал схемы балансировки и даже привел вам ссылку на картинку с логической схемой. Представьте сейчас, вы же можете взять у того же провайдера где вы сейчас берете сервера еще 1 такой же сервер и распределить нагрузку на ваш контент на два сервера... ? если взять ваш голый подсчет и за 100% взять то, что у вас SATA 2 загружен полностью..... то распределив нагрузку на 2 сервера вы уже получите по 50% нагрузки на SATA2 на каждом из них, а соответственно можете догружать еще столько же , до полного отказа. Но эта схема выглядит линейно и пропорционально, но вы не забывайте что часть контента можно отдавать вовсе не используя обращения к винтам, которых так недостаточно в вашей схеме (если это так). Например можно раздавать тот же контент через прозрачный кеш сервер, который загрузит к себе например 10GB контента и будет раздавать их через память... не обращаясь вовсе к серверу с картинками...... так же если вы обратили внимание я использую в обороте фразу "актуальный кеш", я думаю должно быть понятно что не все 62 GB ваших картинок дергают каждый день... некоторые может уже пару лет не дергали.... :))) я думаю, что у динамически обновляемых ресурсов 10-20% контента содержится в кеше и является актуальным. Остальное может через неделю - две удаляться без особых нагрузок в последствии на бекенды при вторичном посещении в кеш (Фактически TCP_MISS или TCP_REFRESH_MISS).

Так не достаточно ему скорости SAS будет , ё мае :) Если у ТС сейчас как он говорит "падает" \ "поднимается", значит уже SATA закончилось (при условии конечно, что проблема в этом)... Поставит он SAS , текущая ситуация разрулится, а через полгода когда посещаемость еще возрастет? ТС станет перед тем же вопросом только уже имея SAS диски, что будете предлагать тогда? + У него контента количество возрастет за это время до 100 GB что в штатные SSD вовсе не влезет. Тут нужна легко масштабируемая схема, а апгрейд железа это далеко не масштабирование :) к решению как таковому не приводит....

64 Gb used ? Так это может и на SSD влезть. Кстати в случае такого мелкого количества контента , актуальный контент для кеширования это наверное гигабайт 10 от силы... :) Можно вообще в память закладывать, тут кто-то на форуме описывал работу базы данных из ramfs :) Так что надо разобраться, если проблема в дисковых i/o то тогда перехода не миновать, ибо SATA 2 достиг своего лимита. Но опять же, можно снизить i/o на сервер путем добавления еще одного нового, сейчас SAS на сколько я понимаю самые быстрые носители? но они дадут всего +100% прироста, согласно скорости 7.200 и 14.ххх.... ну допустим сайт сможет обслужить не 2.5k а 5k сессий..... а что потом? круче SAS (по скорости) на сколько я понимаю только SSD диски, а они однако не дешево стоят. И кстати не совсем мне понятно, зачем заказывать массив 1 TRB при условии использования менее 10% от общего массива (а именно 64 GB ) или у вас послезавтра еще +64 GB планируется? :) Я думаю что этот запас в данном случае есть избытком который для хорошей схемы недопустим.

Работал когда-то с такими чудо контроллерами :) Бесценный опыт :D

Какой серии контролер используете?

А то не капча у вас?:)

Romka_Kharkov добавил 21.03.2011 в 20:05

Обратитесь к оператору в ICQ , готовы обсудить варианты, а так же проанализировать вашу систему.

В пределах вашего бюджета вполне можем предложить интересные варианты построения фермы, вы смотрели пример который я цитировал выше?

P.S: Вы хотите за 1000$ купить решение или арендовать за ~1000$ / месяц?:)