Сучасна диджитал-освіта для дітей — безоплатне заняття в GoITeens ×
Mazda CX 30
×

PCIe SSD в рейд 1

Вобщем будет DC3700 в софтовом рейде.
Всем спасибо ).

👍ПодобаєтьсяСподобалось0
До обраногоВ обраному0
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Рейд-то удалось сделать? Сейчас встали перед такой же потребностью.

Привет. Софтовый рейд тупо.

Привет. А скорость не упала относительно одного диска? И не было ещё повода проверить надежность зеркалирования? Хотим на такую конструкцию основную БД воткнуть, страшно немного.

Падения не видел. На чтении видел космические скорости, постараюсь выложить скрин теста. За год проблем не было. Есть фул бэкап и транзакшн лог бэкап раз в 15 минут, на крайний случай. Насколько я понимаю, для таких дисков жедезячных рейдов не существует.

Для таких дисков придумали Software defined storage, если это 1C (а это в 90% случаев на винде) — читайте про Storage Spaces.

Спасибо. По возможности выложите скрин теста. На следующей неделе будем тестировать в сравнение с СХД на SSD.

А вообще можно как-то выбрать сервер в результате тестирования, не тыкая пальцем в небо? есть такая услуга вообще?

такое может предложить практически любой поставщик
тем более под 1С
ko.com.ua/...anie_servera_pod_1s_66779

Спасибо, самая толковая статья на эту тему, которую встречал.

А кто-то может помочь проверить PCIe диски? Мы купили две штуки, сервер их не видит, думаю, что материнка не тянет, но все-таки хотелось бы проверить. Ну, то есть вставить в тестовый сервак какой-то из свежих? Может есть у кого такое...

Чет мне кажется что у вас траблы с дровами а не с мамкой и дисками.

Все может быть

А кто-то может помочь проверить PCIe диски? Мы купили две штуки, сервер их не видит
дайте попробую угадать — это SSD с NVMe?

Да уже админу кидал эту ссылку, не было еще возможности проверить.

Спасибо за наводку, уже по посту Vitaly Chernooky догадался.

А чем Вас программное зеркало не устраивает ? Если под Linux на уровне Btrfs можно зеркало пользовать.

У нас Виндовс, кроме софтового уже ничего и не получится.

то есть PCIe SSD — исключительно самоцель? просто чтобы было круче чем SAS/SATA SSD?
автор в курсе, что у упомянутого Intel 910 внутри все те же SAS-интерфейсы за мостом PCIe-to-SAS?
основной сценарий использования PCIe SSD в серверах — это READ кеш-акселераторы и для них вопрос отказоустойчивости не является таким острым, как для уровня хранения данных

откуда инфа что ПСИе только для кешей ?

Не круче, а быстрее и надежнее. Речь не просто про PCI, а про корпоративное решение. Что там внутри понятно и не принципиально что там, главное что на выходе.

быстрее
быстрее чем что? чем 4xSSD SAS подключенные через четыре линка к PCIe контроллеру, чем по сути и является Intel 910? вот только SSD SAS/SATA можно будет без проблем подключить к валидированному RAID-контроллеру через hot-plug корзину
и вообще, почему просто не купить готовый сервер с соответствующей дисковой на SSD?

P.S. для справки, 910-й — это предыдущее поколение Intel, которое по любым показателям уступает текущим DC P3700, в том числе по стоимости
P.P.S. никакая реальная одинцэ все равно до максимума подобные устройства нагрузить не сможет — начнет спотыкаться значительно раньше на блокировках

Быстрее, чем есть сейчас.
Мы не пытаемся решить вопросы производительности винтами. Это только часть работы.

лучшее враг хорошего? :-)
текущую нагрузку на дисковую кто-то мерял? не в виде — «все равно хочу чтобы быстрее» а в каких-нибудь реальных метриках — iops, MBps, latency in ms?

Не меряли. Очередь диска скачет до 300, даже 1000 мелькнула. Мерять буду на днях.
Пришло время поменять диски. Места не хватает. Лучше сразу взять хорошие.

Кстати да. Прикольно!
Можно вопрос — а почему тут на нижнем графике (где IO Consistency) такой провал по иопсам примерно на 500 секунде?
www.anandtech.com/...egins-with-nvme

чиво? минимум 20K iops 100% write с платы за ~3K USD это провал? :-)
тогда что у Hewlett-Packard здесь — www.storageperformance.org/...ive-summary.pdf
на другой нагрузке (меньше записи), время отклика >15ms то есть совсем не SSD-ишное...
epic fail в третьей степени? :-)

Вы меня не так поняли — я не сравниваю, а действительно интересуюсь как у специалиста (я не стораджевик).
Понятно, что цифры заоблачные. Но от чего провал? Вангую, что какое-то свойство SSD, но интересно — какое.

Херассе буфер, которого на 8 минут записи по 100к IOPSов хватило! )

))) пацаны говорят что сами не знают
Dangledon — Wednesday, June 04, 2014 — link
Low random write performance is probably an indirect reflection of TLC. The endurance numbers make this pretty clear. TLC has relatively long P/E dwell times. These times become apparent when garbage collection is triggered by sustained random write workloads. I don’t know whether these devices support overprovisioning. Having it might help deal with spikey workloads as long as the “runway” is long enough. Though, frankly, the P3500 was not designed for a high random write workload.
REPLY
Dangledon — Wednesday, June 04, 2014 — link
My bad. They’re using MLC, not TLC. The reserve/spare capacity is 7% on the P3500, which in-part accounts for the relatively low endurance. Intel is probably also doing NAND part binning, using the poorest quality parts in the P3500.

это называется — Write Cliff
таким в разной степени страдают все SSD

Спасибо — прочел.
Век живи — век учись.

не вижу смысла делать raid1. Дублирование серверов и бекапы — простое и железобетонное решение задачи

Дублирование серверов и бекапы — простое и железобетонное решение
... потерять от пары часов до пары суток данных в один прекрасный момент. Причем этот момент обычно значительно ближе, чем кажется.

ну да, расскажите мне про бекапы и восстановление данных :)

судя по

не вижу смысла делать raid
объяснять элементарные вещи действительно бесполезно
просто продолжайте дальше смешить аудиторию собственными анекдотами — twindb.com/...ted-hard-drive

Ну хорошо, давайте оставим элементарные вещи в стороне.
Что именно рассмешило Вас в процитированном анекдоте?

как там у Вас на сайте... Faulty hard drives can give just one chance to read a block
так что просто продолжайте верить в just one chance
главное, ни в коем случае не использовать рейды — вера сильнее здравого смысла

И вот это было смешно? Завидую Вашему чувству юмора.
У меня на столе лежит такой диск. Первый раз мне удалось прочитать почти все. За второй проход прочиталось меньше, ну и так далее пока диск окончательно не умер. К счастью, данные клиента я восстановил. Вот только не понимаю к чему Вы это приплели.
RAID не панацея и в компьютере есть много других железок, которые могут сломаться.
Поэтому есть вот такой подход в построении систем. Использовать простые и дешевые сервера, но с дублированием(третированием(можно так сказать?) ). Гугл, по-моему, первый начал использовать такой принцип и использует до сих пор. Не только он, я видел и трогал такие системы в других компаниях тоже.
Что вы на меня набросились, товарищи продажники?

Наверное, тут разный взгляд.
У Короля ( :-) ) - как на решение. У вас — как на хак.
Ссылка на гугл — незачот: совсем другой уровень разработок/специалистов. И самое главное — создаётся впечатление, что решение с «простыми и дешёвыми серверами» — это такое себе универсальное решение, которое подходит почти везде.
Люди в индустрии, отвечающие за сохранность оперативных данных, понимают, что разработка софта под эти «простые и дешёвые сервера» встанет в такие деньги, что проще уж купить самое дорогое железо, и это обойдётся в десятки-сотни раз дешевле.

Конечно, у нас разный взгляд. У Короля «решения» из powerpoint-a, а у меня — из практики.

Люди в индустрии, отвечающие за сохранность оперативных данных, понимают, что разработка софта под эти «простые и дешёвые сервера» встанет в такие деньги, что проще уж купить самое дорогое железо, и это обойдётся в десятки-сотни раз дешевле.

Простите, но это миф. Ознакомьтесь, хотя бы, с архитектурой фейсбука. Это же открытая информация, они много рассказывают о своих системах. Ниже я привел ссылку на доклад дропбокса, даже той информации достаточно, чтобы опровергнуть Ваше утверждение.

Да вы ознакомтесь с зоопарком приложений банка.
То, о чём вы говорите — гугл, фейсбук, дропбокс — это приложения, изготовленные в самом гугле и фесбуке (я имею в виду флагманов).
А теперь возьмите любой банк, — там этих приложений десятки, и ни одно из них не сделано самим банком, — естественно.
И даже поддержка их, и содержание — не развитие, а фикс багов и стыковка с остальным зоопарком — уже встаёт в копейку!
Самый простой фикс, который делается за 10 минут, обходится в штуку баксов и больше. А вообразить, что приложение нужно переписать, точнее — перейти с одного на другое, — для того, чтобы гонять его на более дешёвом железе — уже вызывает смех!
Потому что вопрос не в железе, — а в том, чтобы понять, какой функционал нужен, в какую сторону двигаться, и каждое приложение выбирается на 8-10 лет, критериев — сотни, и вопросы железа находятся где-то в конце первой сотни (образно).
И написать самим — так вопрос может ставить только, пожалуй, Приват. Что, кстати, для Привата — хорошо, а вот для его сотрудников — не очень.

А вы, вместо того, чтобы вдуматься — какие могут быть проблемы у предприятия с софтом, — вместо этого берёте одно приложение от Dropbox! Одно, которым пользуются десятки, если не сотни миллионов, в отличие от банковского, которым пользуются в лучшем случае сотни людей. А банковское, к тому же, связано с десятком других приложений. И везде речь идёт не о байтах/котиках, а о деньгах и соответствии нормам НБУ/законам страны.

И по поводу «у Короля — из powerpoint’а» — смишно :-)

Это уже по основной работе и через кассу.

Боюсь, что Вы не сможете мне ничего предложить что бы стоило хоть каких-то денег.

Да я вроде и не пытался...

А мне показалось, что пытались, критикуя архитектуру на серверах в простых конфигурациях. И зря, потому что, как минимум, такой подход имеет право на существование и проверен на практике на не самых маленьких системах.

не видишь смысла делать рейд 1 , видишь смысл ставать два сервера ? — я правильно мессадж понял ?

ну так раскажи с какой точки зрения это лучше — больше работы админам, более надежно для данных, более дешево, бо мне кажется ты какой то студент который где то шото слышал про рейды

Крестись, когда кажется. У меня в профайле есть ссылка на линкедин, в отличие от тебя, аноним.

этот ответ объяснил почему нада два сервера.

Уже объяснил. Или чукча не читатель?

давай я задам тебе наводящий вопрос — что у нас с бюджетом.

Обично проект на много нодовой концепции на простом аппаратном «ненадежном» железе стоит дешевле чем схожее по характеристиками одно сервреное «класическое» решениею И обслуживаеие многонодовой системі часто тоже дешевле. Разница часто более чем существеннена. Да и многонодовое вешение часто очень просто маштабируется до практически гигантский размеров чего в класической варианте очень сложно дается и имееб более чем явние рамки.

Вспоминая Oracle и одну базу данних. Какизто 3000 пользователей с не сильно активной нагрузкой ставили в тупик специализированний сервре IBM z серии за много много милионов . И самое главное никто толком не мог сказать, что дальше делать и как подключить следующих 3000 пользователей.

Человек же пишет -сервер 1с, ссд винты стоят уже два года, нужно заменить попутно увеличив скорость и не потеряв в надежности. И тут появляется идея про многонодовый 1с который дешевле по железу, более надежный и более дешевый в обслуживании !!!!!

К чему такая дерзость?! Или ссылка на профиль в LinkedIn дает особые права? На то она дискуссия и спор чтоб рождалась истина.

Максим, чтобы в дискуссии что-то родилось нужно читать и слушать оппонентов. Аноним «mobile mobile» задвинул тему, что «ты какой то студент который где то шото слышал про рейды». На что я ответил ссылкой на линкедин. А Вы не прочитали тред и пишете о какой-то дерзости.

когда вы несете чушь и прикрываетесь своей работой в дропбокс — выглядит ужастно печально для дропбокса.

Иногда поражаешься, насколько гениальна была Фаина Раневская.

— точно так же существуют реализации network raid
— HA/DR-решение за счет дополнительных хостов — это не замена локальной отказоустойчивости конкретного хоста
т.к. это разные архитектурные решения и они преследуют разные цели

"

— HA/DR-решение за счет дополнительных хостов — это не замена локальной отказоустойчивости конкретного хоста
", — это не более, чем лозунг. Потому что высокая доступность системы в целом может достигаться как повышением доступности отдельного компонента, так и дублированием этих компонент. В конце концов, большая доступность самого компонента достигается тем же дублированием (RAID, LAG etc).

Я исходил от поставленной задачи, а не от сферических хадупов в вакууме.
И при текущих условиях идея ТСа является вполне толковой и жизнеспособной.
Если у вас есть решение двухнодовой (с возможностями расширения до 3-4-х) конфигурации MSSQL с соответствующим умножением производительности и полным дублированием данных между нодами без использования веселых шин типа инфинибенда — я бы с удовольствием про него почитал.
Raid1 (да еще и софтовый) все еще остается самым дешевым решением обеспечения отказоустойчивости монолитных систем.
.
Кстати — а какие БД дропбокс пользует? Если не секрет, конечно.

MySQL. Это публичная информация. Например, на прошлой неделе мы делали два доклада о нашей архитектуре и как мы все это саппортим. Петабайты данных (и это только мета-информация, пользовательские файлы лежат в S3), за 300 миллионов пользователей — это сферические хадупы?
Я не специалист в MSSQL, но очень удивлюсь, если в нем нет «двухнодовой (с возможностями расширения до 3-4-х) конфигурации».

UPDATE: Вот, нашел слайды с Oracle Open World oracleus.activeevents.com/...ectTechTalk.pdf

MySQL. Это публичная информация
Да, прочел.
Вопрос — сколько человеко-дней стоило сделать такую масово-параллельную структуру и как давно ушла необходимость в периодическом пинании десятков скриптов-костылей десятками админов?
И последний вопрос — отвечает ли дропбокс деньгами за сохранность пользовательских данных?
но очень удивлюсь, если в нем нет «двухнодовой (с возможностями расширения до 3-4-х) конфигурации»
Можете начинать удивляться. Нет.
Есть только HA, который требует шаред-массива.
Или как вариант «перенесите данные к нам в Азур и платите по пачке денег в месяц».
.
Кстати — salesforce единственный из мне известных облачных провайдеров, который отвечает за сохранность данных клиентов. И (о сюрприз!) работает на одном огромном Oracle RAC.

Ну репликация-то есть у них?
technet.microsoft.com/...v=sql.105).aspx

То есть, уже можно сделать что-то вроде active — standby.

То есть, уже можно сделать что-то вроде active — standby
Что и будет классическим HA.
По итогу стоить будет минимум в 2 раза дороже (это я еще быструю сеть между нодами не посчитал), а работать медленнее (т.к. сеть работает медленнее PCI шины). Но да, будет надежнее за счет дублирования не только винчестеров, но и всего остального.
Вы считаете это сравнимой альтернативой второму винчестеру для случая ТС?

Во-первых, не в два. Потому что а) второй диск нужно еще во что-то воткнуть; б) не зная уровня выше совсем не очевидно, что потребуется что-то дополнительно между нодами и потребуется ли вообще; в) иногда рейд встанет в такую позу, что потом надо потратить чемодан здоровья, чтобы привести его в чувство.
Во-вторых, если дороже, то уже и не альтернатива?
В-третьих, спасибо за дискуссию. Все-то делов — высказал мнение. А выслушал — мама не горюй.

как давно ушла необходимость в периодическом пинании десятков скриптов-костылей десятками админов?
не надо проецировать практики Hewlett-Packard на другие компании :)

Вообще-то я это из презентации вычитал, ссылку на которую вы так любезно предоставили.
Ткнете меня в презентацию с костылями от HP — тогда и обсудим.

это нада в цитатки занести ))) как прочитаю — так и весело ))))

ну занеси, кто тебе не дает?

Це такий хитрий хід, щоб показати два пристрої менш швидкими?
ПС аппаратний рейд це не тільки удобно, но і гарантує великі проблеми при відновленні данних — бо фіг вам хто буде відкривати протокол та кодування рейду

Я помню, давно как-то, полетел рейд с базами 1С. Вместе с винтами.
В эпосе был винт этой модели, но из другой партии и электроника не видела блины. Сисадмину пришлось искать у вендора, кому были проданы винты из той партии (или из завоза, что-то такое). Смогли найти два-три клиента, у всех кроме последнего винты были другой партии, а последний сказал, что можно посмотреть серийник или номер партии за 200 баксов. Как оказалось, это был нужный винт. Теперь за то, чтобы его продать, чувак захотел 10 000 )))).
В общем, бухгалтеры восстановили руками из каких-то старых копий в итоге за месяцок. Но то были некритичные для бизнеса, но критичные для отчетности данные.
Правда 10 лет назад мало кто делал копии каждый день... не говоря уже про в течение дня.

Дефіцит — він такий
Подумайте краще як з ситуації вийти через реплікацію

Горит все и винти и контролери и целие стойки. Репликация помогает но тоже нужно понимать для чего ми єто делаем и что будем дулать в случает Ч

У нас зеркало и архивирование на бэкапный винт с дальнейшим переносом архива с сервера на выделенную машину, на которой складываются архивы.
Это простое решение. О репликации тоже думали, но руки не доходили, пока опыта не было и не успел разобраться.

У меня както УПС с серверной сбойнул и чето не то відал на віходю Все сервреа и много чего просто повіключалось или перешло на паралельний УПС а одному сервру не повезло.
Сгорел блок питания при горении чето пошло на материнскую плату и встроений рейд котролер а там и на винти.

4 SAS винтов в рейде 10 —
живих осталось 1 — не повезло не востановили данние.
Да cервер HP DL 380 gen7
С резервной копией била отдельная история

Мы поэтому храним архивы даже не в офисе, где стоит сервер.
А вообще, конечно практика архивирования у народа слабая. В небольших компаниях данные архивируются редко. Там, где архивируются, то как правило, на диск, на котором лежит и база. Такое вобщем. Но, как правило, после того, как базы полетели, все начинают архивировать ).

Могу посоветовать провети тренинг на востановление резервной копии.
сильно чато копия есть а востановить работу не получается по той или другой причине. И проверяется ето только когда уже укусило ... Заодно узнаете время планового простоя :)

Я об этом думал уже ))). Особенно когда оказывается, что уже неделю не работает архивирование ))).

NVM устройства при полдключении к аппаратному SАТА/SAS RAID будут работать по протокору SАТА/SAS а не NVM. Готовіх аппаратних решений пока гугл не видает.

Драйвера у PCIe SSD пока кастомние и нет единого стандарта.
Дла сегодня я думаю пари PCIe SSD в прогамний рейд будет оптимальний вариант.

Для PCIe нет аппаратных рейдов, поэтому будут работать через свои протоколы, я так понимаю. Я думал сначала, что может есть PCIe-PCIe рейды.
Насколько я понял, NVMe это и есть новый стандарт и по нему выросла производительность.
Программный рейд будем делать.

программний рейд работать будет.
Там в єтих драйверах убрали пару уровней абстракции что собственно положительно сказалось на производительности.
А апаратний рейд появится пренепременно. Не все дисковие решения можно воткнуть в один сервер да и иногда требуется сеть хранения данних и другие плющки которіе без аппаратного решения подключени диска к группе дисков не решить.

Я думаю решения пока не доработано и сейчас активно допиливается.

Вообще общая тенденция развития идей разних кластерних систем идет в отказ от идеи RAID как таковой и задачи с надежностью и доступностью решать не на уровне файловой системі а на уровне приложения.

Ну а если контроллер выйдет из строя?
Файловая система не сильно поможет ведь. К данным же не добраться, если у Эпоса нет такого диска...

диск подключен напрямую к материке и стандартний драйвер то при сгорании материнки вставляете диск в другую материнку и работает дальше.
Если рейд зеркало — то достаточно одного диска из пари для востановления.

Но если у вас хартварний рейд и дохнет котролер — да без такого же котролера жизни не будет.

но есть другая концепция
Данние резервируются и орнанизовіваются не на уровне фаловой системі не на уровне системі как таковой а уже приложениме. Само приложение думает как положить данник куда и на какую ноду что при умирании отдельного диста или ноді все продолжало работать и данник не потерялись.
вот например
cassandra.apache.org
А вот рекомендации по железу
wiki.apache.org/...ssandraHardware

но есть другая концепция
Может быть развита по мере ухода от реляционных хранилищ. Пока в энтерпрайзе (а основные деньги на RnD там, если это не Apple) безраздельно господствуют Оракл сотоварищи, и стараются колоночниками захватить новые ниши типа бигдаты, не нарушая нишу реляционок.

К Ораклу MSSQL и DB2 всегда свой подход бил и железо свое. Особенно если на животинку повелили всего и много много .

Так вся операционная деятельность в мире на них и висит по сути.
За исключением экзотики, которой исчезающее меньшинство пока.
Интересно, кстати, на чем salesforce работает?

Ага, сам нашел. Oracle RAC на 8 нодах. Такие вот пироги...

www.oracle.com/...e/press/1964798
На оракле у них точно шото крутится...

Просто оставлю здесь эту линку
habrahabr.ru/...la/blog/227927

Там в основном про рейд 0. Нас пока не касается ).

рейд 1 тоже ожидает все устройства, то есть, вроде как касается

Ну оно то да. В HDD рейде происходит то же самое, я думаю. Наличие этой проблемы заключается в качестве диска и идентичности характеристик конкретных изделий...

Сам SSD — уже по сути RAID. Флеш-память очень медленна, и потому для её скорости используется огромная степень параллелизма. Никогда не замечал, почему с ростом объёма SSD растёт скорость?

Так что просто откажись от идеи. Всё уже реализовано внутри. Просто возьми SSD нужной скорости и радуйся жизни.

То, что там внутренний рейд это понятно, просто когда полетит контроллер, то ничем уже не поможешь. Тем более рейд там 0, хотя иногда можно настраивать и 1. Поэтому без зеркала не жизнь, хотя можно было бы и обойтись одним, но в случае прецендента как всегда окажется, что бэкап не сделался или еще что-то, поэтому только с зеркалом будем делать.

Как часто летит контроллер? Лишнее звено лишь увеличит вероятность отказа. А вот поставить винт холодным резервом — это запросто. То есть в случае падения ты не теряешь самых свежих данных.

Отдельно продумай нужна ли тебе быстрая запись, или же только быстрое чтение. В этом смысле можно тупо брать винт, а SSD ставить кеширующим устройством. Винт при этом можно брать на 5400 оборотов — у них приемлемая скорость записи, и потрясающая надёжность (за счёт низкой температуры). Кеширующие SSD-решения встретить намного проще. К тому же винт явно поможет с хранением объёма данных.

А насчёт SSD — просто поищи надёжное устройство. Я не думаю что там слетит контроллер просто так, у него логики мало, он не греется. Если глюки за моделью замечены в конкретной серии — о них есть упоминание в сети.

Можешь отдельно опросить на DOU у кого-нить вообще слетал контроллер SSD (кроме серий по которым подтверждены массовые сбои)? Я о таких случаях не слышал. Ещё лучше — поинтересуйся в фирмах которые занимаются восстановлением данных с винтов.

Я по западным форумам читал, слетают контроллеры. И в обычных и в корпоративных винтах, просто в корпоративных реже. Выбрал надежное, интел.
Мы бэкапы делаем в течение дня на обычные винты, с этим все ок.
Работа такая, что процентов 70 нужно читать, а процентов 30 нужно резко быстрая запись. Плюс/минус. Винт не пойдет, ищем более производительное решение.

Резко быстрая запись — решается ОПЕРАТИВКОЙ. То есть именно оперативная память сглаживает пиковую нагрузку. Кеширование записи — задача тривиальная.

Но ещё раз — контроллер SSD в тысячи раз проще и надёжнее, чем контроллер винта. Так что если контроллеры слетают — то в конкретной серии из-за бага прошивки. То есть вся партия и практически с гарантией. Производитель в этом случае должен делать отзыв устройства.

По PCI-Е я о таких случаях не слышал. Хотя бы потому что ОТЛАДКА этих устройств намного проще (шина позволяет кошерно общаться с контроллером), и потому вероятность бага меньше.

Короче, забивай на решения «на коленке», просто ищи надёжное устройство. Обрати внимание, КАКИЕ устройства ставят провайдеры облачного хостинга — думаю, в вопросах надёжности они собаку съели.

По PCI-Е я о таких случаях не слышал.

Были жалобы на проблемы алгоритмов wear levelling (которые как раз отсутствуют в HDD;)), а это не связано с PCI-E.

Ок, спасибо.
Я не четко выразился по поводу записи, резко быстрая — это иногда может длиться пару часов активной записи/чтения при параллельной работе остальных пользователей и еще минимум полночи автоматических всяких обработок. Но в нашей работе, на глаз, операций записи, я думаю, раз в 10 меньше, чем чтения.
Оперативки под SQL отведено сейчас 35 Гб из 48 и планируем еще докупать, как минимум еще 48 можно поставить. Думаю, что это не будет лишним.
Помимо оптимизации кода, настроек и тп, просто на это нужно много времени.

Резко быстрая запись — решается ОПЕРАТИВКОЙ. То есть именно оперативная память сглаживает пиковую нагрузку. Кеширование записи — задача тривиальная.
это бред ©
ни одна СУБД не кеширует ЗАПИСЬ по вполне очевидной причине — это прямой путь к потере данных
в том числе для этого на рейд-контроллерах используется RAM с защитой от потери питания
по этой же причине на не консьюмерских HDD всегда отключена отложенная запись
а на большинстве энтерпрайз SSD включена, потому что у них есть собственные механизмы защиты (от power loss, etc)

Почему бред? Group commit в MySQL — вполне себе кеширование. Или кеш записи с батарейкой — тоже, но на уровне контролера. И в том, и другом случае сохраняется durability свойство.

Group commit в MySQL — вполне себе кеширование.
потому что это вообще не кеширование записи и для него абсолютно не нужно много памяти
при Group commit/commit транзакции/транзакция все равно не будет завершена, пока не будет завершен Sync to disk
и именно тут будет очень большая разница между тем когда запись будет м-е-д-л-е-н-н-о идти на реальный HDD или быстро попадет в кеш отложенной записи, для которого кстати либо все равно — кинут в него несколько мелких блоков или один большой
либо последний вариант с точки зрения производительности даже скорее хуже (больше блок — больше latency записи)

Олег, если я правильно поняла, то все таки есть возможность столкнуться со своего рода кешированием (или буферизацией) данных диском во время коммита транзакции, по крайней мере я это поняла из документации: dev.mysql.com/...g_at_trx_commit
, где сказано:


Caution
Many operating systems and some disk hardware fool the flush-to-disk operation.
  • They may tell mysqld that the flush has taken place, even though it has not
  • . Then the durability of transactions is not guaranteed even with the setting 1, and in the worst case a power outage can even corrupt InnoDB data. Using a battery-backed disk cache in the SCSI disk controller or in the disk itself speeds up file flushes, and makes the operation safer. You can also try using the Unix command hdparm to disable the caching of disk writes in hardware caches, or use some other command specific to the hardware vendor.

    Если я что-то неправильно поняла, объясните мне пожалуйста.
    Заранее благодарна, Олег.

    вот именно что это буферизация, а не кеширование записи

    a battery-backed disk cache in the SCSI disk controller
    уже не имеет никакого отношения к буферизации на уровне DB или ОС — это отдельное аппаратное решение для реализации write-back с собственной RAM, чтобы в том числе сглаживать пиковые нагрузки по записи
    увеличение же RAM на хосте не способно повлиять на скорость записи (посмотрите с чего началась эта ветка дискуссии)
    Винт при этом можно брать на 5400 оборотов — у них приемлемая скорость записи, и потрясающая надёжность
    Эмм — есть другое мнение. Что данные устройства в основном делаются из говна, посему и разлетятся при раскрутке на 7200, не говоря уже о 10к. Зато они дешевые. На чем их преимущества начинаются и заканчиваются.
    А летят они никак не реже, чем нормальные 7200 и 10к.

    А ну, сделай-ка накопитель высокой плотности «из говна». Ты что, из России приехал, а до этого на ВАЗе работал?

    Достоверный факт: основная причина смерти винтов — ТЕМПЕРАТУРА.

    основная причина смерти винтов — ТЕМПЕРАТУРА
    Одна из основных.
    Наряду с неудачной моделью и неудачной партией. Для кровавого энтерпрайза производители массово отзывают эти партии, но для SMB и розницы «и так сойдет».
    Там такие экзотические прохлопы встречаются, что впору книгу писать. Но, увы, все под NDA.

    Собственно — контроллер аппаратного RAID для PCIE должен быть встроен в материнку, причем скорее всего прямо в южный мост.
    Я о таких материнках не знаю на сегодня, посему аппаратный RAID отпадает.
    Но не думаю, что программный так уж сильно тормозить будет — в крайнем случае проц поставьте с большим количеством ядер.
    .
    По tablespaces ораклы — куча гайдов в инете, нет смысла копипастить. Да и от характера работы базы сильно зависит.
    Бекап — я бы поставил какой-нибудь недорогой дедупликатор с САТА вениками. Поглядите сколько у вас за сутки архивлогов набегает и решайте исходя из допустимого времени восстановления. Очевидно, что узким местом скорее всего будет либо сам дедупликатор, либо интерфейс между ним и сервером.

    Я склоняюсь к программному рейду, процы обычно отдыхают сейчас, так что думаю, что будет ок.
    Транзакшн логи сейчас делаются раз в час, на обычный HDD. После перехода на SQL Server 2012 архивирование стало намного быстрее выполняться и + файлы сжимаются быстро, поэтому транзакшн логи можно участить, минут до 15 я думаю.
    Про дедупикатор первый раз слышу, сейчас почитаю. Спасибо.

    Собственно шина скорее всего быстрее захлебнется, чем сожрет все процы.
    Там операции простые как апельсин — размножить запрос на запись, раунд-робин на чтение (и то не факт).
    По бекапу — проведите тест на восстановление, потом эта пропорция от частоты фулл-бекапа сильно поможет при расчетах.

    Ок, спасибо.

    При конфигурации разницы на уровне материнке нет никакой по сравнению с обычными SATA SSD, я собирал Raid 0 из двух таких hard.rozetka.com.ua/..._240gb/p318366

    PCI Raid 1 на SSD как минимум рискованно учитывая ограниченный цикл перезаписи и более низкую надежность SSD. В вашем случае для 1С я бы рекомендовал иметь в зеркалирование на внешние более долговечные HDD, куда сбрасываются бэкапы с вашего SSD RAID-а.

    В целом это геморрой, лучше послушайте mobile mobile и возьмите готовы RAID.

    Рейд 1 — это зеркалирование, 0 — это разделение на 2 потока для производительности. Вы немного ошиблись. Я все понимаю про надежность ССД. Поэтому меня интересовало зеркалирование. Я так понял, что Вы используюете зеркалирование.
    Вы собирали софтовый рейд?
    Мы сейчас применяем рейд 1 на ССД, бэкапы базы и транзакшн логов естественно сбрасываются, даже на другую ненагруженную машину. С этим все понятно.
    Хочется максимум скорости и надежность тут выше. По количеству записываемой информации разница примерно в 2 порядка в пользу PCI (я говорю о корпоративных решениях).
    Из того, что я гуглил, аппаратно они не объединяются, только софтово. Если не найдем аппаратного решения, будем ставить один и делать бэкап транзакшн лога каждые 5 минут.
    Видел видео, где объединяли Ваших 3-4 диска в рейд, но как это было сконфигурировано не понял.

    а разве не 1 — это зеркалирование и высокая скорость чтения за счет двух потоков ? я думал 0 — это просто объединение двух физиков для большего размера.

    RAID 0 — дисковый массив повышенной производительности с чередованием, без отказоустойчивости;
    RAID 1 — зеркальный дисковый массив;
    RAID 2 зарезервирован для массивов, которые применяют код Хемминга;
    RAID 3 и 4 — дисковые массивы с чередованием и выделенным диском чётности;
    RAID 5 — дисковый массив с чередованием и «невыделенным диском чётности»;
    RAID 6 — дисковый массив с чередованием, использующий две контрольные суммы, вычисляемые двумя независимыми способами;
    RAID 10 — массив RAID 0, построенный из массивов RAID 1;
    RAID 50 — массив RAID 0, построенный из массивов RAID 5;
    RAID 60 — массив RAID 0, построенный из массивов RAID 6.

    Правильно, мы используем рейд 1, для надежности.

    Рейд 1 — это зеркалирование, 0 — это разделение на 2 потока для производительности. Вы немного ошиблись.
    Я в курсе.
    Я собирал хардовый рейд, с софтовыми делов не имел, которые прозрачны для ОС. Для максимальной произоводительности я использовал RAID 0, когда полетит один из связки, то все. Производительность RAID 1 такая же как и одного диска, а может даже ниже.

    www.overclockers.com/...yte-Extreme-X58
    Я точно также настраивал на Gigabyte Z68

    ок, спасибо.

    роизводительность RAID 1 такая же как и одного диска, а может даже ниже.
    нет

    Я почему спрашиваю — сам не делал такого никогда, но хочу понять суть вопроса.

    а зачем вам именно PCIe ? есть стандартные бизнес решения -типа плата рейд на ней сата ссд диски. для таких рейдов есть и восстановление и такие рейды легче формировать и вообщем уже лет 20 все работает. Единственное что нада взять плату с нормальной пропускной способностью чтобы они не обрезала скорость дисков, хотя для рейд1 наверно даже встроенного контроллера материнки хватит. Я не видел что стоимость ПСИе дисков дешевле чем сата, но даже если ниже то я не стал бы изобретать велисипед в ущерб нажености.

    Вопрос не в дешевизне, хотя мы планируем недорогие относительно диски. Серия Intel SSD DC P3700 от 1300 USD примерно за 400 Гб. Скорость выше у PCi, по прямым записи/чтении, по IOPSам вообще все круто, выше чем просто взять 2 диска SATA в 0 рейд. На плате для рейда вы поставите скорее всего в лучшем случае 10й рейд из 4х дисков, правильно? Не думаю, что кто-то заморачивается на 24 диска в массиве...
    PCIe SSD, а особенно с последней фишкой NVMe — это конкретно корпоративное решение, с хорошей надежностью и тп (я имею в виду среди ССД, недостатки просто ССД и так понятны), на сегодня это вершина технологий SSD, которые применяются из-за цены в основном в бизнесе.
    Из того, что я прочитал, PCIe SSD можно соединить в рейд только программно. Именно из-за PCI.
    Сейчас мы и так имеем рейд на двух обычных, по-моему Intel 330 в рейд 1, они работают уже почти 2 года и пора их снять уже от греха подальше + причины велосипеда: хочется роста производительности и надежности.

    я не сильно в теме ПСИ ССД, но сколько штук вы можете влепить в сервер ? или какой то расширитель ставится ? Те диски которые я видел — они были не сильно дешевыми по сравнению с обычными сата такой же емкости, но зато с большой скоростью сразу. цену которую вы называете 1300 долларов за 400 гигов — мне кажется завышенной учитывая что у вас 330 счас стоят по центе 150 баксов за 180 гигов или 300 баксов за 300 гигов два года назад.

    Пары штук достаточно, для рейда 1. На материнке хватает разъемов.
    Это не завышено. «Завышено» — это 25000 за IBM PCIe SSD. Куча SAS винтов как это делается для производительной дисковой подсистемы стоит тоже кучу бабла. Особо не встречал в практике, в инете встречались конфигурации за 10-12000 USD.
    Вопрос же не в соотношении цены к суммам, с которыми мы привыкли сами оперировать, а вопрос в соотношении цены к суммам, с которыми оперирует бизнес. С этой точки зрения 1300×2 это дешево. Если вдруг это даст прирост производительности хотя бы процентов на 20-30, это вообще будет круто.
    Вот тут говорят, что переход с 24х SAS-винтов на 8 PCIe SSD дало для базы на Оракл 15-кратный прирост какой-то условной производительности.
    www.principledtechnologies.com/...Ie-SSD_0314.pdf

    ну для этого и ставят ссд — покрыть прирост запросов к базе без покупки нового сервака. я не сравниваю цену к суммам которыми я оперирую, я сравниваю ваш бюджет на ссд раньше и теперь. потому что если что то работает за 500 баксов, а через два года у меня просят уже 1200 баксов на такую же штуку в целях предотвратить возможное падение — то я полюбому не дам. дам теже 500 баксов на обовку а может и 300 — потому что цены на ссд уменьшились.)))

    Тот бюджет ничего не характеризует. Там сервак стоил штук 5-7, я просил, чтобы хотя бы САТА 3 винты поставили, те еще САТА 2, я и так тогда еле уговорил на ССД. Вобщем там сыграл фактор раздолбайства.
    При чем система стоит на SAS рейде 1, один уже меняли. А ССД еще живет.
    Но я думаю, что пора снимать.
    Даже полдня простоя это уже дороже тех 2.5к. Плюс всегда идет поиск повышения производительности, железо это часть этого процесса.

    Важность надежности сохранности данных и постоянного повышения производительности (а вернее компенсации падения производительности по мере усложнения бизнес-логики) вообще всем в данном случае понятна и бюджет на это дело есть )))

    Ну и не в самую последнюю очередь мое любопытство и энтузиазм играет роль.

    Уточнил когда ставили — больше 2.5 лет, точно пора снять.

    Кто-нибудь использовал такие диски для баз данных? Как организовывалось распределение файлов с учетом таких дисков (базы, журнала транзакций, tmbpdb, файл подкачки, бэкапы, частота бэкапов и тп)?

    Ну, может софтовый рейд делал кто-то? Какие результаты?

    Підписатись на коментарі