Comments 86
Надеюсь, тут когда-нибудь появятся предложения магазинов.
Вы не могли бы назвать конкретные цены? Из статьи понял лишь одно — дорого. Но всё же?
Вы не могли бы назвать конкретные цены? Из статьи понял лишь одно — дорого. Но всё же?
Вот все хочу попробовать поставить под MySQL базы SSD диск, но не уверен насколько быстры и как долго проживут SSD у хостера, в моем случае хочу взять у FastVPS (они же hetzner как я понимаю). Если вдруг кто знает хорошего хостера дедиков, порекомендуйте.
А по теме девайс огонь, но дорого и можно поставить только когда сервак «у себя» стоит или на колокейшине.
А по теме девайс огонь, но дорого и можно поставить только когда сервак «у себя» стоит или на колокейшине.
UFO just landed and posted this here
Во, а расскажите, пожалуйста, как резервируете? У вас один диск или зеркало или raid10? Буквально на этой неделе буду реализовывать схему такую.
У нас такая схема, используем зеркало + 3ий диск всегда стоит в Hot Spare Standby + 4ый диск всегда лежит в ящике. Работает уже 1.5 года, за это время 1 раз диск умирал, меняли, вендор заменил по гарантии.
А зеркало аппаратное или программное? Как производительность без TRIM?
Аппаратное зеркало. С батарейной поддержкой кэша на контроллере. Без использования Always Write Back (плохо, но батарейная поддержка спасает). У самого контроллера 1 Гб кэша.
Производительность без TRIM приемлемая — при продолжительной записи производительность за 2 часа (на большее не тестировали) падает с 560 Мбайт/с до 150-200 Мбайт/с. Что всяко быстрей SAS.
Производительность без TRIM приемлемая — при продолжительной записи производительность за 2 часа (на большее не тестировали) падает с 560 Мбайт/с до 150-200 Мбайт/с. Что всяко быстрей SAS.
Тесты весьма печальны www.thg.ru/storage/ocz_revodrive_3_x2_obzor/ocz_revodrive_3_x2_obzor-06.html
К тому же в надежности OCZ я сомневаюсь — для десктопа оно может и круто, но высоконагруженную SQL базу я бы на него класть не стало.
К тому же в надежности OCZ я сомневаюсь — для десктопа оно может и круто, но высоконагруженную SQL базу я бы на него класть не стало.
Извините, но они в разных весовых категориях. Какой-нибудь Яндекс может себе позволить диск ценою в $14000, а у OCZ совсем иной ценник. Себе на сервер, кстати, сейчас выбираем как раз диск из их продукции.
OCZ давно обещает выпустить Z-Drive R5
Я просто оставлю это здесь: 7.2 GB/s, 2.52M IOPS, up to 12TB
Я просто оставлю это здесь: 7.2 GB/s, 2.52M IOPS, up to 12TB
А у Fusion-IO уже очень давно есть Octal www.fusionio.com/products/iodrive-octal/ который не сильно проигрывает еще не вышедшему R5. Вопрос финансов, не технологий.
Мы чуть больше года назад продали клиенту SQL-сервак с 4 SSD Kingston HyperX в рейде. Ттт, пока нормально работает, не сыпется, шустро так крутится. А вот OCZ я бы забздел туда ставить, честно. Много по браку их приносят.
RevoDrive 3 x2 получился неудачным, мягко говоря, лучше посмотрите на RevoDrive 2 x2. А надежность OCZ — вполне, два года под хорошей нагрузкой 24/7 — никаких проблем.
UFO just landed and posted this here
А почему, если полочка уперлась в сеточку, не сделать быстрее сеть? У вас должно быть что-то очень прибыльное, если вы отобьете такой капекс.
Спасибо за обзор, как раз в поисках подобного оборудования
Пожалуйста! Спрашивайте, не стесняйтесь.
Интересует гарантийное обслуживание, срок гарантии и какой ресурс у железки
У нас гарантия на карту под брендом супермикро 3 года — как и на сервер. Если покупать ритейл у Fusion-IO (а я думаю купить у них вполне реально), то дают 5 лет. Понятное дело, что карточек этих в России нету прям здесь и сейчас — так что если не дай бог что-то долгие отправки туда-сюда.
Они также заявляют, что гарантия 5 лет, либо до максимального износа. К сожалению, что такое максимальный износ, они не говорят.
Реселлер (по ритейлу) говорит, что пока ни одного отказа не было зарегистрировано, однако у них не так много покупают — в основном поставки идут через OEM, а они информацией об отказах не делятся.
Они также заявляют, что гарантия 5 лет, либо до максимального износа. К сожалению, что такое максимальный износ, они не говорят.
Реселлер (по ритейлу) говорит, что пока ни одного отказа не было зарегистрировано, однако у них не так много покупают — в основном поставки идут через OEM, а они информацией об отказах не делятся.
UFO just landed and posted this here
Думал о нем, но очень мало информации по нему. У Fusion-IO хитрые технологии обеспечения надежности, у Интела вроде как ничего такого нету.
Ну и собственно выбору Facebook и Apple я доверяю. Задумываться о нем начали после 37Signals 37signals.com/svn/posts/3202-behind-the-scenes-the-hardware-that-powers-basecamp-campfire-and-highrise
Угадали или нет — покажет время.
Ну и собственно выбору Facebook и Apple я доверяю. Задумываться о нем начали после 37Signals 37signals.com/svn/posts/3202-behind-the-scenes-the-hardware-that-powers-basecamp-campfire-and-highrise
Угадали или нет — покажет время.
Если сообществу интересны тесты и кейсы использования Fusion IO под реальные задачи, то оставлю несколько интересных ссылок (где-то месяц назад готовил обзор по внедренному решению, но заказчик не делится результатами):
1. Использование Fusion IO под решение VDI: hp.fusionio.com/assets/files/datasheets/FIO_VDI_Overview.pdf
2. Решение под SQL Server hp.fusionio.com/assets/files/Gen2%20Docs/HP%20Gen8%20SQL%20Server%20Demo%20Sheet.pdf (решение было внедрено у одного заказчика, к сожалению, пока не получили показаний тестов, возможно, в ближайшее время описание решения будет опубликовано).
3. Кейс использования IO Accelerator в решении для MySpace: hp.fusionio.com/assets/files/casestudies/HP%20MySpace%20Case%20Study.pdf
4. Кейс использования IO Accelerator для Datalogix:
hp.fusionio.com/assets/files/casestudies/FIO-HP_DataLogix_booklet_v7.1.pdf
еще одно важное преимущество решений на HP IO Accelerator — быстрый возврат инвестиций: hp.fusionio.com/index.php?id=10
Продукт поддерживается во всех серверных системах как нового, так и предыдущего поколения ( h18006.www1.hp.com/storage/pdfs/HP_IO_Accelerator_for_Bladesystem_cClass_Compatibility_Matrix.pdf ) и может быть предоставлен заказчику для тестирования.
1. Использование Fusion IO под решение VDI: hp.fusionio.com/assets/files/datasheets/FIO_VDI_Overview.pdf
2. Решение под SQL Server hp.fusionio.com/assets/files/Gen2%20Docs/HP%20Gen8%20SQL%20Server%20Demo%20Sheet.pdf (решение было внедрено у одного заказчика, к сожалению, пока не получили показаний тестов, возможно, в ближайшее время описание решения будет опубликовано).
3. Кейс использования IO Accelerator в решении для MySpace: hp.fusionio.com/assets/files/casestudies/HP%20MySpace%20Case%20Study.pdf
4. Кейс использования IO Accelerator для Datalogix:
hp.fusionio.com/assets/files/casestudies/FIO-HP_DataLogix_booklet_v7.1.pdf
еще одно важное преимущество решений на HP IO Accelerator — быстрый возврат инвестиций: hp.fusionio.com/index.php?id=10
Продукт поддерживается во всех серверных системах как нового, так и предыдущего поколения ( h18006.www1.hp.com/storage/pdfs/HP_IO_Accelerator_for_Bladesystem_cClass_Compatibility_Matrix.pdf ) и может быть предоставлен заказчику для тестирования.
В характеристиках очень лукавят.
Latency 0.065ms на запись — это безумно круто. 500кIOPS тоже безумно круто.
Но… Вопрос: а сколько IOPS оно выдаст при сохранении latency <1 ms? И обратный вопрос: какая там latency при 500kIOPS?
Если она способна выдать хотя бы 200кIOPS при 0.1ms — это офигенная вещь. Если у неё при >1kIOPS латенси из микро превращается в мили — то обычная быстрая readonly кешировалка.
Latency 0.065ms на запись — это безумно круто. 500кIOPS тоже безумно круто.
Но… Вопрос: а сколько IOPS оно выдаст при сохранении latency <1 ms? И обратный вопрос: какая там latency при 500kIOPS?
Если она способна выдать хотя бы 200кIOPS при 0.1ms — это офигенная вещь. Если у неё при >1kIOPS латенси из микро превращается в мили — то обычная быстрая readonly кешировалка.
К сожалению 500к мне выжать не удалось, SQLIO падает при блоке меньше 4к, а они обещают такие скорости при 512байтах.
В микросекундах тоже не знаю чем померить, но вот например с очередью 120 (судя по гистограмме все меньше чем за пол миллисекунды — ну это моя догадка, что округляет он пополам).
screencast.com/t/upeliff3LiW5
В микросекундах тоже не знаю чем померить, но вот например с очередью 120 (судя по гистограмме все меньше чем за пол миллисекунды — ну это моя догадка, что округляет он пополам).
screencast.com/t/upeliff3LiW5
Ну, результат читается с трудом, я бы предпочёл посмотреть на fio.
Но выглядит круто. Теперь вопрос: сколько это стоит? (И не забыть умножить на два, т.к. write-операции доверять единичному устройству не стоит).
Но выглядит круто. Теперь вопрос: сколько это стоит? (И не забыть умножить на два, т.к. write-операции доверять единичному устройству не стоит).
$14000 за терабайтную плату.
Т.е. $28k в минимальном конфиге. Заметим, т.к. оно втыкается в PCI-E, то для нормального кластера нужно две головы (а если мамка сдохнет?). Причём в мамку мы не можем воткнуть одну штуку — умрёт, потеряем терабайт данных.
Итого $56k для 1Тб кеша в кластеризованной системе. Заметим, финт ушами в стиле " у нас к дискам multipath" для PCI-E не катит, т.е. нужно делать полное дублирование.
Если указанные попугаи правда, то ок, нормальная система. Если к этому добавить шпиндели в нужном количестве (никакой кеш не спасёт от холодного чтения), то получившееся будет вполне себе сравнимо с нужным числом шпинделей.
Кроме экстремально низкой latency, конечно. Тут её не побить.
Любопытно, сколько будет стоить эквивалентный кеш на базе ramdisk'а…
Итого $56k для 1Тб кеша в кластеризованной системе. Заметим, финт ушами в стиле " у нас к дискам multipath" для PCI-E не катит, т.е. нужно делать полное дублирование.
Если указанные попугаи правда, то ок, нормальная система. Если к этому добавить шпиндели в нужном количестве (никакой кеш не спасёт от холодного чтения), то получившееся будет вполне себе сравнимо с нужным числом шпинделей.
Кроме экстремально низкой latency, конечно. Тут её не побить.
Любопытно, сколько будет стоить эквивалентный кеш на базе ramdisk'а…
Я не совсем понял что ты за систему строишь, но у нас например резервирование на уровне приложения — то есть два одинаковых сервера, в каждом по одной плате. Смысла втыкать вторую плату не вижу, если резервирован сервер целиком.
Вот есть такой линк: 37signals.com/svn/posts/3090-basecamp-nexts-caching-hardware#all_comments (12K за 864GB)
А в комментариях есть про Fusion-IO:
Libo 27 Jan 12
What about some Fusion-IO or equivalent for storage?
Will Jessop 27 Jan 12
@Libo: We use FusionIO in other places, but it doesn’t make cost sense to use FusionIO for a cache that works well in memory as these sticks are being used for.
John 27 Jan 12
Libo
We really like the Fusion-IO cards that we are running in our database servers but in this case it was more cost effective to use memory since we are spreading this across 3 servers.
What about some Fusion-IO or equivalent for storage?
Will Jessop 27 Jan 12
@Libo: We use FusionIO in other places, but it doesn’t make cost sense to use FusionIO for a cache that works well in memory as these sticks are being used for.
John 27 Jan 12
Libo
We really like the Fusion-IO cards that we are running in our database servers but in this case it was more cost effective to use memory since we are spreading this across 3 servers.
PCI-E — уже хорошо, ибо не будет упираться в шину.
Интересно, как оно все же поведет себя при умирании, я так понимаю, что внутри платы реализовано свое зеркало, или нет?
И как плата за $14К сравнится с массивом из (скажем) 4 или 8 SATA3 «обычных» SSD-дисков в RAID10? Тем более что их можно подключить в пару SATA3 PCI-E контроллеров, что несколько уменьшит вероятность умирания такой хранилки… Речь, конечно, о «под серьезной нагрузкой», и об обычных не самых плохих MLC-дисках. Заявленные цифры у таких устройств тоже очень заметные (а если учесть, что они стоят сильно ниже 14К, то «заявленная скорость на доллар цены» у них вполне себе хорошо выглядит.
Знакомые поставили в sql-сервер пару обычных MLC-дисков (IOPS-ов им хватает, так что просто в зеркало). раз в полгода берут новую пару и ставят вместо имеющейся — по их расчетом как раз «пора» менять. Пока живут, дешево и сердито, хотя и «некорпоративно» оно :) Но они как-то при этом верят в получаемый через SMART параметр «процент износа», и не доходят до совсем конца его. Ну и бекапы, конечно :)
Интересно, как оно все же поведет себя при умирании, я так понимаю, что внутри платы реализовано свое зеркало, или нет?
И как плата за $14К сравнится с массивом из (скажем) 4 или 8 SATA3 «обычных» SSD-дисков в RAID10? Тем более что их можно подключить в пару SATA3 PCI-E контроллеров, что несколько уменьшит вероятность умирания такой хранилки… Речь, конечно, о «под серьезной нагрузкой», и об обычных не самых плохих MLC-дисках. Заявленные цифры у таких устройств тоже очень заметные (а если учесть, что они стоят сильно ниже 14К, то «заявленная скорость на доллар цены» у них вполне себе хорошо выглядит.
Знакомые поставили в sql-сервер пару обычных MLC-дисков (IOPS-ов им хватает, так что просто в зеркало). раз в полгода берут новую пару и ставят вместо имеющейся — по их расчетом как раз «пора» менять. Пока живут, дешево и сердито, хотя и «некорпоративно» оно :) Но они как-то при этом верят в получаемый через SMART параметр «процент износа», и не доходят до совсем конца его. Ну и бекапы, конечно :)
Внутри платы есть несколько запасных ячеек, и специальная фирмварь следит, чтобы запись проходила успешно. В случае ошибки контрольной суммы сектора «ремапятся». Статус этого всего отслеживают дрова и софт, чтобы в случае чего предупредить заранее, что ресурс подходит к концу.
Собственно исчерпывание ресурса перезаписей — это единственная проблема SSD.
4-8 дисков требуют места, контроллера, и регулярной замены — у них нет такого хитрого механизма.
Собственно исчерпывание ресурса перезаписей — это единственная проблема SSD.
4-8 дисков требуют места, контроллера, и регулярной замены — у них нет такого хитрого механизма.
Да ну «нет» :)
Есть, и ремапинг есть, просто, возможно, не такая точная диагностика, и не такой запас места под ремапинг. Посмотрите, например, сколько в продаже SSD-винтов на 120 Гб (вместо 128) — вот 8 Гб и ушло под «служебные цели».
В том и вопрос, что непонятно, что лучше. SSD-диски, похоже, менее тщательно разработаны, а обсуждаемые платы — попристальнее, но сам факт, что и там и там косяк может быть, неприятно…
Ну и срабатывает закон «что за что платим». 14K — это тема для «подумать», как ни крути…
Есть, и ремапинг есть, просто, возможно, не такая точная диагностика, и не такой запас места под ремапинг. Посмотрите, например, сколько в продаже SSD-винтов на 120 Гб (вместо 128) — вот 8 Гб и ушло под «служебные цели».
В том и вопрос, что непонятно, что лучше. SSD-диски, похоже, менее тщательно разработаны, а обсуждаемые платы — попристальнее, но сам факт, что и там и там косяк может быть, неприятно…
Ну и срабатывает закон «что за что платим». 14K — это тема для «подумать», как ни крути…
Насколько мне известно, служебные цели в SSD — это не для ремапинга, а для того, чтобы TRIM успевал отрабатывать. То есть они спасают от падения производительности записи при сильно заполненном диске, но если ячейка сдохнет и откажется себя перезаписывать — контроллер просто вернет ошибку.
Ну как бы вопрос цены на самом деле не такой страшный, нужно просто расставить приоритеты. Я вот планирую в ближайшее время собрать сервер под виртуалки на рейде из 520 интелов, и хорошенько нагрузить его тяжелыми приложениями типа билд сервера и тестового сиквел сервера — то что нежалко потерять в случае чего. После 6-12 месяцев тестовой эксплуатации будет ясно, готовы ли обычные SSD на MLC в продакшен или нет.
Ну как бы вопрос цены на самом деле не такой страшный, нужно просто расставить приоритеты. Я вот планирую в ближайшее время собрать сервер под виртуалки на рейде из 520 интелов, и хорошенько нагрузить его тяжелыми приложениями типа билд сервера и тестового сиквел сервера — то что нежалко потерять в случае чего. После 6-12 месяцев тестовой эксплуатации будет ясно, готовы ли обычные SSD на MLC в продакшен или нет.
Тогда «просим-просим» результаты теста. Можно даже дневник жизни системы — прямо как дневник марсохода :)
А насчет потери объема — насколько понимаю (пруф искать некогда, а быстро не нашел) TRIM работает не на этих 8 (скажем) Гб, а на меньшем объеме, и (по крайней мере) часть места все же используется под ремап. Кроме того, современные накопители еще и сжатие на лету делают, чем достигают а) выше скорости и б) освобождения места, которое, опять же, пойдет под ремап и TRIM.
В любом случае, ваш тест был бы кстати!
А насчет потери объема — насколько понимаю (пруф искать некогда, а быстро не нашел) TRIM работает не на этих 8 (скажем) Гб, а на меньшем объеме, и (по крайней мере) часть места все же используется под ремап. Кроме того, современные накопители еще и сжатие на лету делают, чем достигают а) выше скорости и б) освобождения места, которое, опять же, пойдет под ремап и TRIM.
В любом случае, ваш тест был бы кстати!
Прошу прощения, я, конечно, совершенно не в теме, но имеет ли смысл в таком случае использовать RAM диск? Расчёт простой, 1 ТБ памяти стоит порядка $5000, что почти в три раза дешевле описываемого решения. Однако по всем параметрам скорости RAM диск превосходит с большим перевесом. Единственная проблема, данные теряются при перебоях питания или нестабильной работе сервера. Однако это вполне решаемо. Например есть SATA RAM диски со своим питанием и батарейкой. Им не страшна вышеописанная проблема. К сожалению, я не нашёл существуют ли большие RAM диски или на PCI-E.
Взять слабенький сервер натыканый 1ТБ памяти, поставить его рядом с рабочим сервером.
По идее их можно соединить через FC или SAS и получить значительно более быструю СХД.
На этом же сервере независимо можно настроить бэкап из памяти уже на ХДД, или настроить flashcache.
По идее их можно соединить через FC или SAS и получить значительно более быструю СХД.
На этом же сервере независимо можно настроить бэкап из памяти уже на ХДД, или настроить flashcache.
Для сиквела такое решение кардинально не подходит — там важна целостность записываемых данных. SQL сервер даже кешами не пользуется (контроллера и операционки), пишет сразу на диск.
(задумчиво) откуда sql-сервер что-то знает про кеш контроллера? wb и прочие трюки контроллера с батарейкой, конденсатором и т.д. — это не прикладного софта ума дело.
Ну он, очевидно, просто дает системе команду игнорировать кеш.
Вот например iSCSI диск — если снять эту галочку screencast.com/t/zkoCbk7ydoH то по факту кеширование отключится у логического диска на полке screencast.com/t/qyGFa7nJmlpS
Как это реализовано, я, честно говоря, не знаю.
Вот например iSCSI диск — если снять эту галочку screencast.com/t/zkoCbk7ydoH то по факту кеширование отключится у логического диска на полке screencast.com/t/qyGFa7nJmlpS
Как это реализовано, я, честно говоря, не знаю.
Понятно. Так бы и сказали «не знаю».
У прикладного приложения нет ни малейших методов для управления кешем за пределами ОС. Теоретически, существуют механизмы управления write-кешем для дисков (SAS/SATA) и некоторых контроллеров, но никакого общепринятого механизма нет. Соответственно, если рейд-контроллеру в настройках (администратор) сказал «кешировать», то успех на запись будет возвращаться по факту приёма запроса, а не по факту получения подтверждения о записи от диска.
В более сложных системах цепочка ещё дольше. Возьмите, например, XenServer: sql говорит «не кешировать» ос (это называется O_DIRECT), ос послушно пишет в блочное устройство (виртуальное).
А дальше:
* кеш хоста (intellicache)
* запрос уходит на хранилище
* хранилище руководствуется своими мыслями о том, как кешировать
* хранилище передаёт запрос (если он прошёл кеш) в рейд-контроллер
* Рейд-контроллер руководствуется своими мыслями о том, кешировать или нет.
Всё это время приложение пребывает в полной уверенности, что запись завершена.
У прикладного приложения нет ни малейших методов для управления кешем за пределами ОС. Теоретически, существуют механизмы управления write-кешем для дисков (SAS/SATA) и некоторых контроллеров, но никакого общепринятого механизма нет. Соответственно, если рейд-контроллеру в настройках (администратор) сказал «кешировать», то успех на запись будет возвращаться по факту приёма запроса, а не по факту получения подтверждения о записи от диска.
В более сложных системах цепочка ещё дольше. Возьмите, например, XenServer: sql говорит «не кешировать» ос (это называется O_DIRECT), ос послушно пишет в блочное устройство (виртуальное).
А дальше:
* кеш хоста (intellicache)
* запрос уходит на хранилище
* хранилище руководствуется своими мыслями о том, как кешировать
* хранилище передаёт запрос (если он прошёл кеш) в рейд-контроллер
* Рейд-контроллер руководствуется своими мыслями о том, кешировать или нет.
Всё это время приложение пребывает в полной уверенности, что запись завершена.
Да, изнутри виртуалки он естественно ничего не знает о сторедже, и знать не может.
Однако, еще раз говорю, что на физической машине SQL открывает файлы данных используя FILE_FLAG_NO_BUFFERING == true.
И система уважает его мужественное решение. Конкретно наша полка (а я так думаю, что любая нормальная тоже) отдает логический диск в виде LUN по iSCSI, и система видит эти настройки кеширования — для нее это обычный диск. И может их менять.По крайней мере в винде, не знаю как в этих вашх линуксах.
И если приложение говорит не кешировать — она не кеширует.
Вот записал видео, как это выглядит:
screencast.com/t/EyXrlVewT
Однако, еще раз говорю, что на физической машине SQL открывает файлы данных используя FILE_FLAG_NO_BUFFERING == true.
И система уважает его мужественное решение. Конкретно наша полка (а я так думаю, что любая нормальная тоже) отдает логический диск в виде LUN по iSCSI, и система видит эти настройки кеширования — для нее это обычный диск. И может их менять.По крайней мере в винде, не знаю как в этих вашх линуксах.
И если приложение говорит не кешировать — она не кеширует.
Вот записал видео, как это выглядит:
screencast.com/t/EyXrlVewT
Расскажите, каким образом, например, в iscsi, можно сказать «не кешировать»? Как только трафик выходит за пределы хоста, там больше нет «этих ваших windows» и «этих наших linux».
ЗЫ ссылка не работает, там какие-то плагины требуют.
ЗЫ ссылка не работает, там какие-то плагины требуют.
Adobe Flash Player хотят.
Я уже сказал, что я не знаю каким образом оно работает — но оно работает. У меня в задачах есть запись, что надо его поковырять, но времени пока нету.
Я уже сказал, что я не знаю каким образом оно работает — но оно работает. У меня в задачах есть запись, что надо его поковырять, но времени пока нету.
Предположу: там, возможно, есть протокол, который и говорит контроллеру, можно ли кэшировать или нельзя, нет? И во всей цепочке, если она правильно реализована, команды должны поддерживаться? Ну, это в качестве теории.
Давайте я задам другой вопрос: откуда оратор знает, что wb нет в одних случаях и он есть в других?
Ну, он показал в скринкасте, как винда включает и выключает (на живую, причем) кэш виртуального диска из полки при изменении в веб-интерфейсе самой полки соответствующих настроект. Правда, не показал, можно ли это делать с другой стороны — со стороны Win. Т.е. в настройках диска в Win выключить кэш — изменится ли настройка LUN на полке.
Что же касается конкретно вашего вопроса — ответа на него у меня нет.
MS SQL открывает свои базы с FILE_FLAG_NO_BUFFERING == true, это значит, что кэш ОС отключается точно. Отключается ли при этом кэш диска — мне неизвестно (хотя, можно поискать в Сети). Но если отключается, то есть интерфейс для этого, а если есть интерфейс, он должен быть реализован на всех слоях виртуализации.
Что же касается конкретно вашего вопроса — ответа на него у меня нет.
MS SQL открывает свои базы с FILE_FLAG_NO_BUFFERING == true, это значит, что кэш ОС отключается точно. Отключается ли при этом кэш диска — мне неизвестно (хотя, можно поискать в Сети). Но если отключается, то есть интерфейс для этого, а если есть интерфейс, он должен быть реализован на всех слоях виртуализации.
В обратную сторону тоже работает, поверьте, пожалуйста, на слово.
Ключевой момент в том, чтобы это ушло дальше среды виртуализации. То есть виртуализация это хорошо, но я не понимаю, каким макаром это пройдёт до шпинделя. Заметим, в nfs есть режим открытия sync/async, но большинство систем СХД, которые я видел, имеют настройки, которые синк/асинк делают вне зависимости от мнения клиента. Ну и уж тем паче, асинк и синк NFS не влияют на мнение о wb у рейда под файловой системой (на сторедже).
Проверить мне в голову не приходило. Сейчас проверил — кеш юзается всегда.
Снимаю шляпу.
Снимаю шляпу.
Глупости не пишите. 1ТБ памяти это уже не слабенький сервер, потому что ему надо уже как минимум несколько процессоров, чтобы получить доступ к этой памяти, а также высокопроизводительный бэкэнд, чтобы эти данные прокачивать, также выше было обозначено то, что RAM — энергозависим, и при потери питания все данные будут утерены. Тем более, как вы собрались получить доступ к памяти по FC или SAS?
Что-то более менее похожее, что вы описываете называется In-Memory Computing, например SAP HANA, у которой все данные находятся в памяти, а резервирование идёт на уровне узлов. Но эти продукты используются для очень высоконагруженных ERP систем, где нужно не просто, например, логи быстро писать, а анализировать огромные массивы данных в единицу времени. Т.е. довльно-таки специфические задачи. Да и решение по стоимости не сравнимо с парой SSD или Flex-IO.
Что-то более менее похожее, что вы описываете называется In-Memory Computing, например SAP HANA, у которой все данные находятся в памяти, а резервирование идёт на уровне узлов. Но эти продукты используются для очень высоконагруженных ERP систем, где нужно не просто, например, логи быстро писать, а анализировать огромные массивы данных в единицу времени. Т.е. довльно-таки специфические задачи. Да и решение по стоимости не сравнимо с парой SSD или Flex-IO.
Глупости, это не учитывать перспективу времени, по отношению к железу в ИТ.
Сейчас в тренд врываются и будут господствовать планки по 32ГБ.
Сейчас они конечно стоят неподъемно, но еще чуть-чуть и устаканится.
Мат. плата с 32 планками стоит 20к. руб.
Да, 2 процессора, самых слабых ничего не мешает туда воткнуть.
>>Тем более, как вы собрались получить доступ к памяти по FC или SAS?
На стороне нашего сторэджа, из памяти, делается блочное стройство.
На линуксе это делается штатными средствами.
Проблема питания в нашем веке успешно решает УПС.
К тому же, вы проглядели flashcache.
Возможностей масса.
Дело не в этом. Просто это не энтерпрайзно как скажут многие.
Вы вообще знаете из чего делается железо СХД многих известных вендоров, к примеру IBM?
Сейчас в тренд врываются и будут господствовать планки по 32ГБ.
Сейчас они конечно стоят неподъемно, но еще чуть-чуть и устаканится.
Мат. плата с 32 планками стоит 20к. руб.
Да, 2 процессора, самых слабых ничего не мешает туда воткнуть.
>>Тем более, как вы собрались получить доступ к памяти по FC или SAS?
На стороне нашего сторэджа, из памяти, делается блочное стройство.
На линуксе это делается штатными средствами.
Проблема питания в нашем веке успешно решает УПС.
К тому же, вы проглядели flashcache.
Возможностей масса.
Дело не в этом. Просто это не энтерпрайзно как скажут многие.
Вы вообще знаете из чего делается железо СХД многих известных вендоров, к примеру IBM?
То что это не энтерпрайзно это само собой =)
2 самых слабых процессора, самая дешевая и слабая материнка, потом ещё самому собрать. А в чём собственно профит? Доступ к данным быстрый, а обрабатываться они будут сколько? Вы решите одну проблему, получите другую.
Даже если замапить RAM disk сервера как LUN на другом, в чём не вижу никакого смысла, и не представляю как это реализовть (расскажете, скажу спасибо), то мы получим опять задержки на контроллерах, от которых автор топика и хотел уйти. Зачем это? Да и УПС не вечен.
А что flashcache? Это не панацея, по многим причинам. Для примера кэшу ещё нужно разогеться, что не допустимо там, где выполнить задачу нужно здесь и сейчас, а не ждать пока данные в него попадут.
Знаю, и не по наслышке из чего делают СХД. Но причём тут это?
2 самых слабых процессора, самая дешевая и слабая материнка, потом ещё самому собрать. А в чём собственно профит? Доступ к данным быстрый, а обрабатываться они будут сколько? Вы решите одну проблему, получите другую.
Даже если замапить RAM disk сервера как LUN на другом, в чём не вижу никакого смысла, и не представляю как это реализовть (расскажете, скажу спасибо), то мы получим опять задержки на контроллерах, от которых автор топика и хотел уйти. Зачем это? Да и УПС не вечен.
А что flashcache? Это не панацея, по многим причинам. Для примера кэшу ещё нужно разогеться, что не допустимо там, где выполнить задачу нужно здесь и сейчас, а не ждать пока данные в него попадут.
Знаю, и не по наслышке из чего делают СХД. Но причём тут это?
Например IBM Storwize, это x86 интел процы и серверная память, 8 ГБ по делофту чтоль
С установленным линуксом.
Вполне себе mid-range СХД.
Здесь мы реализовавываем то же самое, только вместо дисков на той стороне, мы имеем здоровенную оперативку и диски произвольного объема.
>> " обрабатываться они будут сколько?"
Вы имеете в виду скулевым сервером или что?
>>Для примера кэшу ещё нужно разогеться
Ну так он будет разогреваться на старте системы.
С установленным линуксом.
Вполне себе mid-range СХД.
Здесь мы реализовавываем то же самое, только вместо дисков на той стороне, мы имеем здоровенную оперативку и диски произвольного объема.
>> " обрабатываться они будут сколько?"
Вы имеете в виду скулевым сервером или что?
>>Для примера кэшу ещё нужно разогеться
Ну так он будет разогреваться на старте системы.
RAM актуально для кеша — ценные данные никто в здравом уме хранить там не будет. В нашем же случае там будут лежать базы сиквел сервера, и постоянная запись файлов данных и логов транзакций.
A вы не могли бы на это дело поставить винду 8 и загрузиться в неё? Мне так, просто из интереса, чтобы поржать о скорости и поплакать о своей конфигурации.
А нам вот только Fusion-IO ioDrive Duo приехал, тестим, в противовес ему едет OCZ Z-DRIVE R4 и приехали 4 OCZ Vertex 4 в рэйд… поглядим-с, хотя ioDrive Duo выбивается из этой компании своей несвежестью :/
Duo требуют дополнительного питания и видятся в системе как два накопителя. Плюс, первое поколение очень тормозное по сравнению со вторым — его обычные SSD уже догнали наверное.
Z-Drive — просто пара вертексов, распаянная на рейд-контроллере. Вертексы хороши в десктопах, в продакшен я бы пихать не стал, если честно. У нас вертексы под систему в продакшене используются, ну там записи практически нету.
Z-Drive — просто пара вертексов, распаянная на рейд-контроллере. Вертексы хороши в десктопах, в продакшен я бы пихать не стал, если честно. У нас вертексы под систему в продакшене используются, ну там записи практически нету.
Не знаю, у нас без доп.питалова работает спокойно.
первое поколение очень тормозное по сравнению со вторым
Второе, к сожалению не трогал, а вот первое… когда я его первый раз воткнул в Dell`овский сервак на прошлой неделе и поставил последний дрова с офф.сайта, получил ~200мб/с, сегодня переткнул в HP`шный (кстати у нас ioDrive Duo под лого HP) и с дровами с сайта HP (который 3.1.1 не доступные на офф.сайте) я получил уже ~800. А вот то что он виден как 2 диска это я понимал, правда думал что у него всё-таки есть свой RAID контроллер и опечалился надписью — Soft RAID.
просто пара вертексов, распаянная на рейд-контроллере
пара не пара, но всего 1 слов и 1,6Тб — порой это актуально, а по производительности — сравним с вертексами, благо уже на складе лежат.
Я вот только не могу придумать «реальных» тестов для сравнения, одна синтетика :(
первое поколение очень тормозное по сравнению со вторым
Второе, к сожалению не трогал, а вот первое… когда я его первый раз воткнул в Dell`овский сервак на прошлой неделе и поставил последний дрова с офф.сайта, получил ~200мб/с, сегодня переткнул в HP`шный (кстати у нас ioDrive Duo под лого HP) и с дровами с сайта HP (который 3.1.1 не доступные на офф.сайте) я получил уже ~800. А вот то что он виден как 2 диска это я понимал, правда думал что у него всё-таки есть свой RAID контроллер и опечалился надписью — Soft RAID.
просто пара вертексов, распаянная на рейд-контроллере
пара не пара, но всего 1 слов и 1,6Тб — порой это актуально, а по производительности — сравним с вертексами, благо уже на складе лежат.
Я вот только не могу придумать «реальных» тестов для сравнения, одна синтетика :(
Возможно, я изучал только второе поколение, там красными буквами написано про доп.питание.
Сравнить со вторым можно по характеристикам на сайте.
Дрова очень важно, да, плюс прошивку нужно обязательно последнюю использовать. Софт рейд официально поддерживается (в винде или линуксе, не важно) — но вот Brent Ozar писал, что у него были проблемы в такой конфигурации — поищите в гугле.
Экономия места и скорость — да, согласен. Но вопрос надежности меня смущает. Я жутко переживал когда мы начали SSD под систему испоьзовать — но уже больше года полет нормальный, начинаю успокаиваться понемногу.
Лучше перебздеть, чем недобздеть, как говориться.
Сравнить со вторым можно по характеристикам на сайте.
Дрова очень важно, да, плюс прошивку нужно обязательно последнюю использовать. Софт рейд официально поддерживается (в винде или линуксе, не важно) — но вот Brent Ozar писал, что у него были проблемы в такой конфигурации — поищите в гугле.
Экономия места и скорость — да, согласен. Но вопрос надежности меня смущает. Я жутко переживал когда мы начали SSD под систему испоьзовать — но уже больше года полет нормальный, начинаю успокаиваться понемногу.
Лучше перебздеть, чем недобздеть, как говориться.
Мы, кстати, выпустили весной аналогичную FusioIO опцию — Express Flash. Тот же флеш на PCIe, но с возможностью хот-плаг и в перспективе загрузки с носителя. Из интересного — подключается к шине через одну плату (x16) до четырёх модулей (x4) и экономит слоты. Выбор объёмов только маловат пока — 175 и 300Гб.
А «вы» это кто?
до четырёх модулей
т.е. я так понимаю 4х300Гб максимальный объём? А как с производительностью?
до четырёх модулей
т.е. я так понимаю 4х300Гб максимальный объём? А как с производительностью?
Упс, забыл представиться — Dell :) и заодно опечатался, не 300, а 350. Т.е. можно до 4 по 350Гб сделать на топовых моделях (R720, R820).
Производительность есть маркетинговая (не будем её тревожить :) ), есть whitepapers с замерами по конкретным случаям (SQL, Exchange, Oracle RAC) — там в основном смотрят на TPS или отклик. Достигают в 2-3 раза больше, чем обычно.
Надавно в офис привезли ситему с поддержкой — как раз думад прогнать тесты, чтобы сравнить с Fusion-IO, которые мы поставляем. Если на выходных удастся, то выложу пост. Пока на уме RHEL + fio/ORION
Производительность есть маркетинговая (не будем её тревожить :) ), есть whitepapers с замерами по конкретным случаям (SQL, Exchange, Oracle RAC) — там в основном смотрят на TPS или отклик. Достигают в 2-3 раза больше, чем обычно.
Надавно в офис привезли ситему с поддержкой — как раз думад прогнать тесты, чтобы сравнить с Fusion-IO, которые мы поставляем. Если на выходных удастся, то выложу пост. Пока на уме RHEL + fio/ORION
А поделитесь ценой на Z-Drive, пожалуйста, можно в личку.
Коллеги, подскажите, какой утилитой провести IO тесты?
UFO just landed and posted this here
Добавил небольшой апдейт про износ ячеек.
Sign up to leave a comment.
Первый взгляд на Fusion-IO ioDrive2