Комментарии 13
Когда звучит имя производителя контролеллеров SSD SandForce, сразу приходит в голову анекдот, про то что ложечки то нашлись, а осадок остался. Особенно для таких нетерпимых к потере даных областей как SQL
Если при покупке полагается выделенный инженер, то я даже боюсь спрашивать, сколько стоит это Чудо-Юдо.
Что делает фирмваря, когда в ней происходит ошибка, а данные в кеше, и внешнего питания уже нет? Я понимаю, сейчас мне расскажут про сверхвысокую надёжность кода, в котором нет ошибок. Ок, ок. А если есть?
Где цифры производительности? Я вижу какие-то графики в стиле «а вот если линейку вот так вот прикладывать, то у меня на 2см SSD длиннее». Сколько sustained random iops на запись выдаёт? При какой латенси?
Наличие батарейки означает writeback, то есть реальная производительность устройства ниже? Какие цифры получаются, если writeback отключить? И можно ли его отключить? (А то я видел халтурные китайские поделки, которые даже если им сказать «отключи writeback» радостно продолжали всё writeback'чить).
Где цифры производительности? Я вижу какие-то графики в стиле «а вот если линейку вот так вот прикладывать, то у меня на 2см SSD длиннее». Сколько sustained random iops на запись выдаёт? При какой латенси?
Наличие батарейки означает writeback, то есть реальная производительность устройства ниже? Какие цифры получаются, если writeback отключить? И можно ли его отключить? (А то я видел халтурные китайские поделки, которые даже если им сказать «отключи writeback» радостно продолжали всё writeback'чить).
Если нет внешнего питания, FW завершает все операции, сохраняет таблицы и паркует устройство. При любых ошибках происходит блокировка устройства. Подобная практика применяется во всех устройствах.
В случае, когда ZD-XL работает в паре с Z-Drive, пользовательские данные всегда записываются как в КЭШ, так и на СХД с подтверждением записи. Как и было ранее написано, при загрузке или перезагрузке, старый КЭШ удаляется, т.к. нет гарантий его полной синхронности с данными на СХД. Для этого и применяется разогрев КЭШ.
Просьба не путать работу FW железки и ПО кэширования, хотя они и тесно интегрированы. Отказ железки при применения ZD-XL не приводит к потери данных, просто перестанет работать КЭШ, ПО перестанет его использовать, выдаст сообщение о необходимости провести замену оборудования.
Сама железяка способна восстановить ошибки длиной до 55 бит из 512 битного сектора, все остальное — детектируется.
Наличие батарейки не связано с Writeback, а требуется для сохранения целостности данных в полёте и таблиц при внезапном отключении питания, для предотвращения потери данных и превращения SSD в «кирпич».
ZD-XL не пишет только в КЭШ, более того сам движок не встаёт на пути данных и их через себя не пропускает. Данные, что идкт на запись, так и идут прямиком на СХД и пока они не будут этой СХД записаны, и будет выдано подтверждение следующая операция не выполняется, параллельно, движок решает, стоят эти данные того, что бы попасть в КЭШ или пускай только пишутся на СХД. Фактически, все вновь созданные данные или изменённые всегда пишутся либо только на СХД, либо на СХД и в КЭШ, когда данные требуются вновь, они уже доступны из КЭШ.
Что касаемо железки и её характеристик, OCZ была одна из первых, кто стал публиковать данные по производительности в устоявшемся режиме после прекондиционирования.
Детальные характеристики: ocz.com/enterprise/download/guides/zdrive_4500_datasheet.pdf
Графики приведены из стати, там все подробно рассказано, какие конкретно системы применялись, какую проблему решали и что получилось при применении ZD-XL. Полный документ можно запросить вот тут ocz.com/enterprise/literature/white-papers/accelerating-microsoft-sql-server-2014-workloads-with-flash
Как и множество других, описывающих реальные и самые интересные примеры внедрения ZD-XL. (Да, OCZ хочет знать кто интересуется их решениями...)
Публиковать самые лучшие показатели задержек на голой синтетике — перестали, ибо смысла в них — нет. Нужно всегда учитывать данные и рабочие нагрузки, а они у всех и каждого — разные.
Что касаемо сравнения с «халтурными китайскими поделками», то OCZ — американская компания, входящая в группу компаний Тошиба и принадлежащая американскому подразделению Тошибы. Z-Drive был разработан командами английских и американских разработчиков, а ПО ZD-XL — командой израильских разработчиков, более того, OCZ вообще первыми сделали PCIe SSD и до сих пор остаются единственными, кто имеет аппаратную виртруализацию NAND на самом устройстве. У конкурентов PCIe SSD — это фактически банальные переходники на NVMe, M.2, или SATA.
В завершении хочу еще раз обратить внимание — ZD-XL — это комплекс из железа и ПО, прошу его так и рассматривать.
Работу SQL на голых SSD — нужно рассматривать отдельно — тема эта интересная, без условно, в таком варианте все работает гораздо быстрее, но и сложностей, затрат и подводных камней при этом — больше.
В случае, когда ZD-XL работает в паре с Z-Drive, пользовательские данные всегда записываются как в КЭШ, так и на СХД с подтверждением записи. Как и было ранее написано, при загрузке или перезагрузке, старый КЭШ удаляется, т.к. нет гарантий его полной синхронности с данными на СХД. Для этого и применяется разогрев КЭШ.
Просьба не путать работу FW железки и ПО кэширования, хотя они и тесно интегрированы. Отказ железки при применения ZD-XL не приводит к потери данных, просто перестанет работать КЭШ, ПО перестанет его использовать, выдаст сообщение о необходимости провести замену оборудования.
Сама железяка способна восстановить ошибки длиной до 55 бит из 512 битного сектора, все остальное — детектируется.
Наличие батарейки не связано с Writeback, а требуется для сохранения целостности данных в полёте и таблиц при внезапном отключении питания, для предотвращения потери данных и превращения SSD в «кирпич».
ZD-XL не пишет только в КЭШ, более того сам движок не встаёт на пути данных и их через себя не пропускает. Данные, что идкт на запись, так и идут прямиком на СХД и пока они не будут этой СХД записаны, и будет выдано подтверждение следующая операция не выполняется, параллельно, движок решает, стоят эти данные того, что бы попасть в КЭШ или пускай только пишутся на СХД. Фактически, все вновь созданные данные или изменённые всегда пишутся либо только на СХД, либо на СХД и в КЭШ, когда данные требуются вновь, они уже доступны из КЭШ.
Что касаемо железки и её характеристик, OCZ была одна из первых, кто стал публиковать данные по производительности в устоявшемся режиме после прекондиционирования.
Детальные характеристики: ocz.com/enterprise/download/guides/zdrive_4500_datasheet.pdf
Графики приведены из стати, там все подробно рассказано, какие конкретно системы применялись, какую проблему решали и что получилось при применении ZD-XL. Полный документ можно запросить вот тут ocz.com/enterprise/literature/white-papers/accelerating-microsoft-sql-server-2014-workloads-with-flash
Как и множество других, описывающих реальные и самые интересные примеры внедрения ZD-XL. (Да, OCZ хочет знать кто интересуется их решениями...)
Публиковать самые лучшие показатели задержек на голой синтетике — перестали, ибо смысла в них — нет. Нужно всегда учитывать данные и рабочие нагрузки, а они у всех и каждого — разные.
Что касаемо сравнения с «халтурными китайскими поделками», то OCZ — американская компания, входящая в группу компаний Тошиба и принадлежащая американскому подразделению Тошибы. Z-Drive был разработан командами английских и американских разработчиков, а ПО ZD-XL — командой израильских разработчиков, более того, OCZ вообще первыми сделали PCIe SSD и до сих пор остаются единственными, кто имеет аппаратную виртруализацию NAND на самом устройстве. У конкурентов PCIe SSD — это фактически банальные переходники на NVMe, M.2, или SATA.
В завершении хочу еще раз обратить внимание — ZD-XL — это комплекс из железа и ПО, прошу его так и рассматривать.
Работу SQL на голых SSD — нужно рассматривать отдельно — тема эта интересная, без условно, в таком варианте все работает гораздо быстрее, но и сложностей, затрат и подводных камней при этом — больше.
Расскажите пожалуйста, чем отличается подобное решение от размещения баз на обычном SSD или массиве SSD дисков?
Не совсем понял из статьи.
Не совсем понял из статьи.
При использовании ZD-XL база данных так и остаётся на дисковых томах в SAN. Нет необходимости что-то менять. Все, что можно сделать дополнительно — перенести TempDB на flash том ZD-XL.
Установка ZD-XL это — быстро.
1. Отключение сервера для добавления PCIe накопителя
2. Установка ПО и одна перезагрузка для поднятия драйверов и старта служб движка.
3. Помощник конкурирования (сервер уже работает и обслуживает пользователей), выбор разделения на TOМ под TempDB и КЭШ, выбор, чего ускорять, перенос TempDB на TOM Flash
4. Задание сценариев автоматизации прогрева КЭШ для выполнения аналитики или отчетов, специфических задач, тонкая оптимизация и подстройка.
Новые системы — конечно сразу нужно делать на Flash. Это максимально быстрая система.
PCIe имеет тут преимущество, т.к. задержки существенно будут меньше, чем у SATA или внешних FLASH СХД, т.к. каждое соединение FC, SAS, Ethernet — это дополнительные задержки.
Установка ZD-XL это — быстро.
1. Отключение сервера для добавления PCIe накопителя
2. Установка ПО и одна перезагрузка для поднятия драйверов и старта служб движка.
3. Помощник конкурирования (сервер уже работает и обслуживает пользователей), выбор разделения на TOМ под TempDB и КЭШ, выбор, чего ускорять, перенос TempDB на TOM Flash
4. Задание сценариев автоматизации прогрева КЭШ для выполнения аналитики или отчетов, специфических задач, тонкая оптимизация и подстройка.
Новые системы — конечно сразу нужно делать на Flash. Это максимально быстрая система.
PCIe имеет тут преимущество, т.к. задержки существенно будут меньше, чем у SATA или внешних FLASH СХД, т.к. каждое соединение FC, SAS, Ethernet — это дополнительные задержки.
Да, еще забыл упомянуть, что при работе с большими базами данных, экономически эффективнее часто применять ZD-XL, т.к. не вся база часто используется и хранить её всю на Flash — дороговато, а вот работать с её «горячими» областями, которые переносятся в КЭШ и размещая TempDB на томе Flash — весьма удобно.
Чем будет отличаться ваше решение от обычного SSD диска/массива, на котором мы разместим TempDB базы?
По тестам PCIe и SATA существенно не отличаются — www.3dnews.ru/820040/page-2.html#Результаты в CrystalDiskMark
По тестам PCIe и SATA существенно не отличаются — www.3dnews.ru/820040/page-2.html#Результаты в CrystalDiskMark
Скоростью, значительно более низкими задержками, надежностью, наличием end to end data protection, отсутствием необходимости иметь свободные слоты и порты под SATA…
И как справедливо замечено ZD-XL — это решение, можно и TempDB туда положить и кэшировать, одновременно, причем кэшировать можем базы огромного размера, сотни ТБ!
Тесты CrystalMark и подобные пакеты, не способны показать всю печаль (да и делали их для маркетинга SSD), на которую обрекают себя люди, решившие использовать SSD потребительского класса в серверах или серверных нагрузках. Эти же тесты демонстрируют, что серверные SSD вообще не имеют смысла, т.к. они медленнее получаются своих потребительских собратьев по тестам CrystalMark и аналогам.
Люди не понимают, что размер тестового файла у «попсовых» пакетов — десяток, максимум сотня мегабайт. Их запускают на SSD обязательно после Secure Erase и без прекондиционирования, один раз, без достижения ssd steady state.
Их задача показать максимум, сферического коня в вакууме, а что там потом — это не важно… Как этот SSD будет работать после одной перезаписи?
Plextor M6e — это обычная попытка продать залежалые M2 хоть как-то… Результаты на запись и смешанными блоками — у него печальные… Ну не серверный это SSD…
Потестируйте настольные SSD с помощью HammerDB… hammerora.sourceforge.net/
Всё сами поймёте. Пока базу только создадите, большая часть потребительских SSD просто сдохнет либо физически, либо будет медленнее HDD…
Ну или хотя бы по SNIA… (да жёстко, но все правда вылазит, т.к. тесты делали не маркетологи, а инженеры) www.snia.org/tech_activities/standards/curr_standards/pts
Когда получите вот такой ужас: greentechreviews.ru/wp-content/uploads/2014/08/1_iops1.png
надеюсь начнёте осторожнее пользоваться CrystalMark для принятия решений, о том какой SSD ставить и куда…
Хочется хотя бы вот как-то так, или лучше greentechreviews.ru/wp-content/uploads/2014/04/iops_final.png
И вот так… greentechreviews.ru/wp-content/uploads/2014/04/saturation_final.png
А вот, что показал ZD-XL при тестах HammerDB.
ru.ocz.com/enterprise/company/news/zd-xl-tested-at-nt4admins-germany-
Вся статья на немецком, если кому захочется почитать… www.nt4admins.de/themen/applikationen/artikel/zd-xl-sql-accelerator-beschleunigt-sql-server.html
Честно говоря, не ожидал такого вопроса, да же обидно, прям как будто не читали…
ZD-XL — это когда нет возможности или желания, что-то кардинально менять в железе. Это решение для существующих систем!
Если есть возможность все поставить на SSD — ставьте на SSD сразу!!!
Собираете новую систему — все на SSD — сразу! Да, так будет быстрее всего!
И как справедливо замечено ZD-XL — это решение, можно и TempDB туда положить и кэшировать, одновременно, причем кэшировать можем базы огромного размера, сотни ТБ!
Тесты CrystalMark и подобные пакеты, не способны показать всю печаль (да и делали их для маркетинга SSD), на которую обрекают себя люди, решившие использовать SSD потребительского класса в серверах или серверных нагрузках. Эти же тесты демонстрируют, что серверные SSD вообще не имеют смысла, т.к. они медленнее получаются своих потребительских собратьев по тестам CrystalMark и аналогам.
Люди не понимают, что размер тестового файла у «попсовых» пакетов — десяток, максимум сотня мегабайт. Их запускают на SSD обязательно после Secure Erase и без прекондиционирования, один раз, без достижения ssd steady state.
Их задача показать максимум, сферического коня в вакууме, а что там потом — это не важно… Как этот SSD будет работать после одной перезаписи?
Plextor M6e — это обычная попытка продать залежалые M2 хоть как-то… Результаты на запись и смешанными блоками — у него печальные… Ну не серверный это SSD…
Потестируйте настольные SSD с помощью HammerDB… hammerora.sourceforge.net/
Всё сами поймёте. Пока базу только создадите, большая часть потребительских SSD просто сдохнет либо физически, либо будет медленнее HDD…
Ну или хотя бы по SNIA… (да жёстко, но все правда вылазит, т.к. тесты делали не маркетологи, а инженеры) www.snia.org/tech_activities/standards/curr_standards/pts
Когда получите вот такой ужас: greentechreviews.ru/wp-content/uploads/2014/08/1_iops1.png
надеюсь начнёте осторожнее пользоваться CrystalMark для принятия решений, о том какой SSD ставить и куда…
Хочется хотя бы вот как-то так, или лучше greentechreviews.ru/wp-content/uploads/2014/04/iops_final.png
И вот так… greentechreviews.ru/wp-content/uploads/2014/04/saturation_final.png
А вот, что показал ZD-XL при тестах HammerDB.
ru.ocz.com/enterprise/company/news/zd-xl-tested-at-nt4admins-germany-
Вся статья на немецком, если кому захочется почитать… www.nt4admins.de/themen/applikationen/artikel/zd-xl-sql-accelerator-beschleunigt-sql-server.html
Честно говоря, не ожидал такого вопроса, да же обидно, прям как будто не читали…
ZD-XL — это когда нет возможности или желания, что-то кардинально менять в железе. Это решение для существующих систем!
Если есть возможность все поставить на SSD — ставьте на SSD сразу!!!
Собираете новую систему — все на SSD — сразу! Да, так будет быстрее всего!
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
OCZ ZD-XL SQL Accelerator. Enlarge your SQL