А что щас не говно ? Сигейты наверное остались единственные которые не дохли партиями, сериями и пачками. Кого не возьми - все лажанулись. Что бимеры с дятлами, что фуджитсу с мпг-шками, что потом макстор с наследием фуджиков. Самсунги никогда не сверкали, western digital повально в конце 90-х у всех попередохли. А брэнды типа micropolis и miniscribe в бозе давно почили.
Гонять сервер на IDE/SATA ... неразумно. Лучше уж SATA NE (Seagate Near End начиная с 250ГБ, все что меньше - годится только для десктопов и entry-level файловиков), если бюджет СКАЗИ не позволяет. А так будете менять винты каждые год-полтора. Это я Вам говорю как врач (с)
>> А так будете менять винты каждые год-полтора. Это я Вам говорю как врач (с)
что я не так делаю, если все мои винты доживают до возраста моральной старости? Вот до сих пор валяются 2 и 3 гиговые сигейты и работают сцуки, только нафиг они мне нужны, никак не пойму? ;-)
О как! Это новость. Нет! Это НОВОСТЬ. Великий ДИМЫЧ сподобился просветить недоумков. А вы, уважаемый, никогда не удивлялись, что львиная доля современных серверов имеют жесткие диски на IDE/SATA? Вы никогда не интересовались предложениями провайдеров о выделенных серверах?
>бюджет СКАЗИ не позволяет
SCSI - это миф. Технология SCSI (несмотря на "реинкарнацию" в виде SAS) в настоящий момент скорее мертва, чем жива. Хорошо разрекламированная технология, которая вот уже сколько премени существует только за счет набранных очков уважения в далеком прошлом.
Объяснение простое: в далеком прошлом, IDE жесткие диски умели только PIO. Соответственно, обмен данными с ними был довольно неэффективным: требовалось много ресурсов процессора. SCSI за счет пакетной модели взаимодействия и специальных контроллеров было быстрее. С развитием DMA/UDMA технологии доступа к дискам, разница в производительности для "рядовых" пользователей свелась к нулю: все стало упираться только в RPM. SCSI винты с 15000rpm, конечно, несколько быстрее обычных 7200rpm винтов, но даже менее чем в 1.5 раза: дело в том, что "обычные" винты позволяют записывать информацию более плотно.
Кроме того, современные PATA/SATA диски вполне предусматривают "горячую замену". Да и потоки (NCQ) они тоже поддерживают.
Легендарная "надежность" SCSI-дисков тоже миф. Технология производства пластин - абсолютно одинаковая (я считаю вас разумным человеком: вы ведь не думаете, что производители вкладывают миллиарды на развитие двух независимых технологий производства пластин). Относительная "надежность" достигается попросту меньшей плотностью записи (что в итоге снижает производительность). С развитием технологии "перпендикулярной записи" "надежность" SCSI дисков становится абсолютным мифом, более того, SCSI диски становятся ущербными в связи с очень малым объемом хванимой информации: 36Гб (что сравнимо с твердотельными носителями, при абсолютно более высокой пропускной способностью последних), 72Гб и 147Гб против 500/750/1000 Гб у IDE/SATA.
>А так будете менять винты каждые год-полтора
Бред. IMHO, в данном случае проблема именно с дисках производства Seagate, а вовсе не в выбранной технологии интерфейса.
>Это я Вам говорю как врач (с)
- Ара, а ты где на агронома учился?
- В сельскохозяйственном техникуме!
(с) Гоблин.
Сарказм - сарказмом, но опыт показывает: SCSI до сих пор незаменимы для хостинга БД с серьезными нагрузками. Даже PATA/SATA диски с перпендикулярной записью имеют гораздо более низкий предел кол-ва записей (читай - запросов к БД) чем SCSI. Не говоря уже о MTBF. Помножьте вероятность фолта на количество дисков в массиве = получится что диск(и) придется менять каждые год-полтора.
Конечно, если нагрузки маленькие, то можно и на флэшке пользоваться БД...
А быстродействие SCSI в основном зависит от NCQ (поправьте, если ошибаюсь), чего PATA/SATA до сих пор не научились толком делать.
> - Ара, а ты где на агронома учился?
Проработал 3 года в фирме специализирующейся на оптовых поставках серверного оборудования, на собственном опыте убедился что SCSI возвращают гораздо реже чем IDE (а покупают - чаще).
> Помножьте вероятность фолта на количество дисков в массиве = получится что диск(и) придется менять каждые год-полтора.
Давайте сделаем терабайтный массив для файлового сервера? Емкостью какой-нибудь жалкий терабайт например. Можно сделать массив из 14-ти SCSI по 140GB (страйп на 7 дисков + полное зеркалирование). Пусть каждый из винтов стоит "какие-то жалкие 600 баксофф" - мы же "энтерпрайзами" мыслим, для нас это копейки. В общем одни диски выльются примерно в 8 килобаксов. Второй вариант - сделать массив на SATA-дисках (4 диска по 250GB + зеркало). В общем винты здесь будут стоить в районе 800 баксов... Очень значительная экономия, не находите? Можно хоть каждый год менять весь комплект дисков - все равно это будет выгодней. И кстати да - не надо рассказывать сказки про производительность, мы тестировали кучу железа (в т.ч. SCSI) и предельный подъем с диска был не выше 130МБ в секунду.
> убедился что SCSI возвращают гораздо реже чем IDE (а покупают - чаще).
Сервера обычно имеют SCSI на борту изначально, а IDE-контроллеры там так... Для DVD-привода. Поэтому естественно что SCSI будут чаще покупать. Что же до возвратов - так тоже вполне понятно. IDE в большинстве своем ставятся в железки, которые достаточно часто перегружаются и выключаются - поэтому и летят часто. На предыдущей работе у нас собралась интересная статистика - практически все сдохшие винты (кроме тех что умерли "от возраста" - типа лет пять им уже было) сдохли при перезагрузке. Выключили свет надолго -> гасим сервера -> включаемся -> части винтов нет, делаем замену.
>SCSI - это миф. Технология SCSI (несмотря на "реинкарнацию" в виде SAS) в настоящий момент скорее мертва, чем жива.
Ух ты. Новое слово в синтезе галюциногенов :-)
> Конечно, если нагрузки маленькие, то можно и на флэшке пользоваться БД... никак неможно, никто из производителей этого не пишет, но на самом деле флеш память имеет довольно ограниченное кол-во записей-перезаписей.
Да нет, пишут обычно. Только люди легко ведутся на большие цифры, типа "миллион перезаписей!", думая, что это круто. И им влом подсчитать, что только на массовых записях логов такая флешка полностью выработает ресурс через пару месяцев :)
>Я даже промолчу про MBTF (хотя рекомендую сравнить). Но какой IDE/SATA выдержит хотя бы месяц непрерывного сика? :) SCSI так могут работать годами.
Вы, уважаемый, хоть бы собственному совету последовали, что ли, а то звездеть на LORе все горазды...
http://www.westerndigital.com/ru/products/index.asp?cat=2
Корпоративный класс:
WD Raptor: SATA и скоростью вращения 10000 об/мин MTBF 1,2 млн. часов при 100% нагрузке
* К сведению: 1.2 млн часов - это почти 137 лет.
WD RE2: SATA, 7200, MTBF 1,2 млн. часов при 100% нагрузке
WD RE: SATA/PATA, 7200, 1 MTBF 1 млн. часов при 80% нагрузке
WD Raptor:
Объем буфера 16 МБ
Циклы запуска/останова контактов Не менее 20 000
Время поиска
Время поиска при считывании 4,6 мс
Запись времени поиска 5,2 мс (в среднем)
Время перехода с дорожки на дорожку при считывании 8,9 мс (в среднем)
Время поиска при полном ходе головок 10,2 мс (в среднем)
Скорость передачи данных
Чтение из кэша накопителя (Serial ATA) максимум 1,5 Гб/с
Из буфера на диск 84 МБ/с (постоянная)
Гарантия 5 лет
WD RE2:
Seek Times
Read Seek Time 8.7 ms
Track-To-Track Seek Time 0.6 ms (average)
Full Stroke Seek 21.0 ms (average)
WD Cavair SE16 (десктоп):
Время поиска
Время поиска при считывании 8,9 мс
Запись времени поиска 8,9 мс (в среднем)
Время перехода с дорожки на дорожку при считывании 2,0 мс (в среднем)
Время поиска при полном ходе головок 8,9 мс (в среднем)
Забавно, правда? При обычном поиске RE2 будет чуть-чуть быстрее десктопного Caviar, а вот при полном ходе головок - почти в 2.5 раза медленнее.
>Вы, уважаемый, хоть бы собственному совету последовали, что ли
Одно из двух, или ты тролль, или совершенно не разбираешься в железе. Ибо пример Раптора тут не характерен, это не правило, а исключение. При чём ты либо об этом знаешь (и тогда это просто троллинг с твоей стороны), или не знаешь, но тогда - нафига лезешь?
А так - кстати, да. Хорошо, что ещё напомнил про банальный RPM. Тоже фактор в пользу SCSI :)
> no-dashi:
> Давайте сделаем терабайтный массив для файлового сервера?
> Емкостью какой-нибудь жалкий терабайт например.
> Можно сделать массив из 14-ти SCSI по 140GB
> (страйп на 7 дисков + полное зеркалирование)
> [skip]
> Второй вариант - сделать массив на SATA-дисках
> (4 диска по 250GB + зеркало).
Т.е. собираем RAID 1+0 ? Ок.
Всё это прекрасно. Но есть несколько НО!
БОльшая чать стоимости дисковых массивов - это цена RAID контроллера или что чаще бывает - двух RAID контроллеров. По сравнению с его стоимостью, цена диска не кажется такой уж большой. Естественно речь идёт о внешних массивах (на которые я так понял тут был "наезд").
Если предлагается обойтись четырьмя слотами под винты и одним PCI слотом, тогда для надёжности нужно будет иметь соотвествующую обвязку к этим дискам - дублированые блоки питания в сервере, host swap корзины. Что тоже увеличивает стоимость.
Второй момент - чем больше элементов входит в stripe (мы же говорим про RAID 1+0), тем меньше нагрузка на отдельно взятый диск. Соответсвенно будет меньше проседание по вводу/выводу на большом количестве random IO. Соотвествующие эксперементы можете провести сами или поискать результаты в Inet-е.
Третий момент - внешние массивы из более-менее современных как минимум имеют 1Gb cache (чаще 4-8Gb). А сколько имеют те же Intel-овские и прочие контроллеры в PCI исполнении ? И на что это влияет ? Вобщем понятно...
Червёртое - о надёжности/отказоустойчивости: у внешних массивов как правило дублированые RAID контроллеры с зеркалирование cache и возможностью замены на ходу, дублированые блоки питания, встроеные аккумуляторы для питания cache памяти на случай пропадения питания (то что всё это подключаться должно через UPS даже не подлежит обсуждению). Что может произойти с данными при отказе PCI-ного контроллера, пропадении питания, сбое на motherboard ? Возможно ничего, но вот я несколько раз видел после сдыхания материнской платы развалившиеся RAID-ы (при этом сам RAID контроллер был исправен).
Пятое - как там насчёт добавки дисков к RAID-у ? Без потери данных и останова ? Назовите мне такой контроллер в PCI исполнении. Нет, я конечно допускаю, что сильно отстал от жизни и такие продаются на каждом углу...
Оно конечно, если несколько часов простоя не критичны, то можно хоть на soft raid прожить, но если час простоя стоит несколько десятков килобаксов (примеров таких контор - масса), то вариант со самосборным RAID массивом явно не канает.
> БОльшая чать стоимости дисковых массивов - это цена RAID контроллера или что чаще бывает - двух RAID контроллеров.
Сантехники замечательно живут на софторейде солстик вот уже ХЗ сколько времени, да и в zfs рейд далеко не хардварный. Если не организовывать массивы типа RAID-5, то софторейд вполне конкурентный выбор.
> Второй момент - чем больше элементов входит в stripe (мы же говорим про RAID 1+0), тем меньше нагрузка на отдельно взятый диск. Соответсвенно будет меньше проседание по вводу/выводу на большом количестве random IO.
Время сика сильно пропорционально углу - а он как раз практически одинаков. Зависимость там далеко не линейна. Впрочем даже если и так - никто не мешает добить массив SATA-шными винтами до количества сказевых - это все равно в два раза дешевле при в два раза большей емкости.
> Третий момент - внешние массивы из более-менее современных как минимум имеют 1Gb cache
Ну и что? Если вы внимательно читали например доку к СУБД, то помните что 1. там идет потоковая запись (причем с ожиданием окончания сброса данных из кэша) и следующий блок не пишется пока не записан предыдущий и 2. нужные данные всегда рядом в своем собственном кэше. Я также видел насколько этот "не-СУБД" кэш малоэффективен. Кстати у ОС также есть свой кэш - на порядок эффективней чем этот контроллерный.
> Второй момент - чем больше элементов входит в stripe (мы же говорим про RAID 1+0), тем меньше нагрузка на отдельно взятый диск. Соответсвенно будет меньше проседание по вводу/выводу на большом количестве random IO.
Время сика сильно пропорционально углу - а он как раз практически одинаков. Зависимость там далеко не линейна. Впрочем даже если и так - никто не мешает добить массив SATA-шными винтами до количества сказевых - это все равно в два раза дешевле при в два раза большей емкости.
> Третий момент - внешние массивы из более-менее современных как минимум имеют 1Gb cache
Ну и что? Если вы внимательно читали например доку к СУБД, то помните что 1. там идет потоковая запись (причем с ожиданием окончания сброса данных из кэша) и следующий блок не пишется пока не записан предыдущий и 2. нужные данные всегда рядом в своем собственном кэше. Я также видел насколько этот "не-СУБД" кэш малоэффективен. Кстати у ОС также есть свой кэш - на порядок эффективней чем этот контроллерный.
> Пятое - как там насчёт добавки дисков к RAID-у ?
Добавить диск к linear ли mirror? Да легко :-) Впрочем - вы конечно можете начать нам рассказывать про "ентерпрайзовые XYZ", вот только тогда сначала лучше расскажите как вы будете УБИРАТЬ диск из массива :-)