Дисковая подсистема для domino

[akat]

Приветствую, коллеги!

Есть ли у кого-то опыт использования Лотусовых баз на сервере на SSD-дисках?
Если да, то какие использовали?

 

[ToxaRat]

самые дешевые - полностью отказался от рейдов5
всё стало летать

все обещали что я их за год запилю - всё еще работает

радует что, что в процессе "запила" диски просто превращаются в RO - что как бы бекап

изначально система на 5 отдельных логических дисках свелась к одному физическому SSD

и залетало

 

[alexas1]

свелась к одному физическому SSD

Без зеркала не стрёмно?

 

[oshmianski]

3 SSD Samsung 840 Pro 128Gb, 1 HDD WD 2TB

1 SSD - System
2 SSD - Data
3 SSD - View rebuild index dir + TL
4 HDD - DAOS + Backup

Но у меня система не очень нагружена. Уже больше года полет нормальный, тьфу-тьфу.

 

[rinsk]

Без зеркала не стрёмно?

Если в кластере - то не стремно.
Пока на SSD translog\log\FTindex и самые нужные базы - подбиваю на замену вообще всех дисков на SSD (кроме sys ест-сно).

 

[akat]

Спасибо всем неравнодушным

@oshmianski, прямо как в бэст прэктис
Building a high performance Domino Server
link removed

 

[lmike]

подбиваю на замену вообще всех дисков на SSD (кроме sys ест-сно).

зависит от IO - можно и кэшированием обойтись типа

Ссылка скрыта от гостей

[DOUBLEPOST=1426682393,1426682118][/DOUBLEPOST]

3 SSD Samsung 840 Pro 128Gb, 1 HDD WD 2TB

1 SSD - System
2 SSD - Data
3 SSD - View rebuild index dir + TL
4 HDD - DAOS + Backup

Но у меня система не очень нагружена. Уже больше года полет нормальный, тьфу-тьфу.

для 1Це делал

Ссылка скрыта от гостей

в режиме writethrough (WB не рискнул) сразу все тупки пропали
ато iotop казал жуть
пихнул в варианте dkms - обновления ядра не страшны, 3 месяца пашет
попадание в кэш 99% диск 128Гб A-Data

Ссылка скрыта от гостей

+ тома

Ссылка скрыта от гостей

 

[lmike]

в чем + от такого решения - если накроется ssd - ничего не произойдет акромя падения производительности

 

[oshmianski]

@lmike, как-то все очень сложно звучит, но, видимо, шкурка выделки стоит

 

[lmike]

там ничего сложного нет - все прозрачно описано...
"единственное" ядро уже далеко не 3.9 (да и не нужно)
git clone https://github.com/stec-inc/EnhanceIO.git
иначе (как по ссылке) ошбку вывалит (ключей-то ssh нету)
ну и ветку брать master (т.е. НЕ переключаться на бранч git checkout 3.9-kernel)
остальное по контексту (даты там и прочее)
[DOUBLEPOST=1426686309,1426686061][/DOUBLEPOST]

шкурка выделки стоит

хотябы потому, что я могу один SSD использовать для разных дисков, с разным алгоритмом (т.е. на уровне партишенов SSD определяем кэш)

 

[ToxaRat]

Без зеркала не стрёмно?

у меня не бывает одного сервера, а при наличии реплик одних и тех же БД на разных сервера - бекап уже не нужен

 

[lmike]

бекап уже не нужен

ну давай пофантазируем...
реплики получили несинхрон (сервер падал, время разбежалось, БД имеет к-л траблы)
замечено сразу не было...
а тут, чу... лепяздричество ушло упс не сработал, диск получил повреждения не сопоставимы с жизнью
и именно на сервере с ценными кусками инфы
гордый своим запасным сервером - достал, вывалил..., ан хрен - нетути доков
у нас в серверной - здоровый АПЦ на 3-и стойки, запросто сбоил (тупо отрубался при пропадании фаз), а там и фирма и гарантии - толку-то.
а це другой случай - ЦОД в UK , генератор, все дела...
чу..., в ходе штатного тестирования генератора - "что-то пошло не так" - генератор не переключил к-ту хрень, ИБП не сработали...
цирк с конями - ЦОД рухнул, жалкие оправдания из европы (де - не должно было, все дела...)

@ToxaRat, а ты продолжай не делать бэкапы

 

[rinsk]

ну давай пофантазируем...

Ну фантазировали и не раз "Программное" разрушения баз в 99.9% случаев происходит на одном из серверов кластера. Я имею ввиду всякие там BTREE error, NIF corrupt и т.п.
Никогда не видел что это было на 2-х серверах сразу. Бакап с кластером имеет смысл только если прогнозируется логическое уничтожение или искажение данных - типа Ctrl+A \ Del ...
При соблюдении условий кластер вполне себе работает консистентно с разбегом в секунд 5 макс. и в любом случае - данные будут гораздо актуальнее чем бэкап.

 

[lmike]

@rinsk, то что я перечислил - это реальные случаи из моей только практики
реплики могут быть несинхронными по разным причинам
на серваке кластера может тупо быть ФС попорчена (а его считали бэкапом )
и бэкап существует не только для актуальных данных, но против вандализма/глупости/раздолбайства
и дизастер никто не отменял (пожар/маскишоу...)

 

[ToxaRat]

@rinsk, то что я перечислил - это реальные случаи из моей только практики
реплики могут быть несинхронными по разным причинам
на серваке кластера может тупо быть ФС попорчена (а его считали бэкапом )
и бэкап существует не только для актуальных данных, но против вандализма/глупости/раздолбайства
и дизастер никто не отменял (пожар/маскишоу...)

как страшно ты живешь

в моем практике был лишь один случай когда действительно появилась потребность в "бекапе" - когда админ одного из моих купленных за 5 баксов серверов(естественно не в нашей стране) начал пытаться меня шантажировать - типа включу сервер и получишь назад свои данные но только за деньги - по его анализу у меня было:
- всё чётко настроено
- куча баз
- веб
- почта
- аналитика
- загрузка,
- за 3 месяца работы базы увеличились в 10 раз
- я не разу не делал бекап(не было сессии с большим обьёмом трафика)
- якобы чтобы так всё работало я потратил минимум 2 месяца работы на одну лишь настройку!
Как минимум тут есть на чём срубить капусту(он требовал штуку баксов)

меня это тогда сильно улыбнуло - реплики есть, ID сервера есть, сервер был поднят и настроен за 2 часа, админ был послан а новый сервер был поднят за 10 минут, всего-то потребовалось подправить в DNS A запись на новый IP и я не потерял ни одного байта данных из 10 гигов!
так что бекапы - это вот для таких админов, которые не понимают, чем домино отличается от "стандартов общества"

 

[lmike]

так что бекапы - это вот для таких админов, которые не понимают, чем домино отличается от "стандартов общества"

бэкапы - это необходимость, когда осознание придет - может оказаться поздно
реплики кот. были - это тоже бэкапы и за ними нужно следить
в дополнение могу сказать - подъем виртуалки (синхронизированной) - это минут 5-ть

 

[rinsk]

Ну давайте слона есть по частям

реплики могут быть несинхронными по разным причинам

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

на серваке кластера может тупо быть ФС попорчена (а его считали бэкапом )

Как один из серверов кластера может быть более "бэкапным" чем другой? Они как бэ равнозначны. и какой на конкретный момент более актуальный - ну решается на месте. А вот надежда на чистый "бэкап" имеет рисков минимум в 2 раза больше чем в случае с кластером (разрушение диска с бэкапом).

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

Соглашусь со второй частью. Ибо именно вопрос актуальность бэкапа для данных - вызывает сомнения.
А теперь - хотелось бы вспомнить, что такое "бэкап" и с чем его едят
Имхо правильный бэкап - версионинг это по формуле 5+1. 5 рабочих дней инкрементал + 1 день полный. Интересно, сколько стоит такая система для Домино сейчас? Когда то пользовался таким продуктом как Legato Networker. оч прикольная штука и очень дорогая. Умеет восстанавливать подокументно на любой отрезок времени. Выкинули. Ибо за 5 лет не понадобился ни разу.
Копии файлов? То же делали. Согласно регламенту (Stop server\Copy file\Start server). Ни разу не понадобилось. Ибо проще было на проблемном сервере убить базу и восстановить там с другого сервера кластера, чем отлавливать приплывшийе удаленные документы и т.п.
Повторю\дополню свой тезис - бэкап для серверов домино в кластере имеет смысл если только есть риск несанкционированного искажения\удаления данных и не принято никаких административных, организационных и программных средств для избежания подобного. Фактор рассыпания дисков в кластере имеет минимальный вес. Но - тут надо понимать какие в этом случае возникают риски и проблемы с самим бэкапом - например если тупо копировать базы, то в бэкапе так же окажутся искаженные данные - и тю-тю. Несколько копий? ну-ну... не знаю как у других - у меня около 0,5 -1 ТБ на серверах. Спасет только Backup Agent от промышленной системы резервного копирования. Но согласно последним веяниям к нему нужно будет приставить дополнительного админа. И сам бэкап надо содержать на надежных носителях (или "кластер" носителей).
Короче - плюнул я на это дело пока и обхожусь штатными механизмами
add: И да - тред возник из за вопроса - не стремно ли без раида в кластере?

 

[lmike]

Как один из серверов кластера может быть более "бэкапным" чем другой? Они как бэ равнозначны.

чистая условность в контексте обсуждения

и какой на конкретный момент более актуальный - ну решается на месте. А вот надежда на чистый "бэкап" имеет рисков минимум в 2 раза больше чем в случае с кластером (разрушение диска с бэкапом).

а вот здесь вопрос - как построена схема бэкапов и как разнесены сервера кластера, как пример (и он уже упоминался, не мной) просто фриз для ВМ, снэпшот, анфриз, синк (синхронизация изменений), бэкап (разный бывает), удаления снэпшота.
фриз нужен только на момент снэпшота (кот. мал по времени)
ВМ может синкаться целиком (предпочтительно) или частями (т.е. только данные без ОС)
Далее все это отправляется на ленту (так сказать - "для истории")
я не убеждаю против кластера, но его может не быть по разным причинам (денежный в т.ч.) и основное предназначение его несколько отличное от просто резервного сервера

И сам бэкап надо содержать на надежных носителях (или "кластер" носителей).

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

 

[lmike]

не стремно ли без раида в кластере

за 3-и года я "потерял" 5-ть SATA дисков, на своем рабочем компе (сегейты и один WD, но щас не об этом)
причем есть тонкости поведения дисков в ходе ошибок...
SATA,

Ссылка скрыта от гостей

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

 

[lmike]

хотя это уж оффтоп...

Ссылка скрыта от гостей

это тесты "обычных" сата дисков

ниже кучка сентенций в стиле капитанства
сказя (SAS, SCSI) дает выигрыш во времени доступа и обработке одновременных запросов (в т.ч. чтения и записи) - ну т.е. при интенсивных операциях с множеством "клиентов"
отсюда и разница в цене (есть еще и фактор скорости вращения, но он затрагивает только "классические" HDD) и т.п.
из циферек (по ссылке) видно, что "классические" диски достигают до 160 мб/с "в прыжке" (в реальности будет хуже - ок. 100) при чтении
потому и используют SSD, они способны дать 300 (в среднем, циферьки тоже можно найти в

Ссылка скрыта от гостей

)

т.о. для нагруженного по IO сервера лучше SAS + SSD (что очевидно), очевидно и то - что цена такого решения является кусачей
для сокращения расходов - SSD ставят как кэш (что описывал выше) и этим не "гнушаются" богатые компании (фэйсбук - как пример), ибо одновременно, ко всему объему хранения доступ практически не осуществляется
т.е. круто, конечно, впиндюрить SSD (да еще в зеркле) на постановку туды ОС и гордиться попугаями, но..., йопыт, подсказывает - этож пустая трата денег

еще о бренчании пальцами
вернее - о вдумчивом отношении к расходам
SATA подходят для стораджей с бэкапами и мало-нагруженных файлопомоек, а вот с кешем из SSD вполне могут справляться и с более "серьезными" задачами

в кач. кэша имеют смысл объемы 128-256Гб (последний предпочтительнее), меньший объем "совсем плох" по характеристикам (несмотря на то - что его хватило бы в кач. кэша)
технология

Ссылка скрыта от гостей

(SLC в разы долговечнее, но медленнее и значительно дороже)

Особенности материнок для обычного сегмента, с SATA (это отступление для очень бюджетных вариантов)
SATA 3 там бывает не на всех каналах (а часто - на одном), встроенный mSATA разъем, часто (а с тем что я сталкивался - всегда) не является SATA 3 (вот такая шутка от вендоров)
т.е. - замысливая поставить SSD в самосборный "сервер" не стоит покупать mSATA носитель (позарившись на разъем в материнке)
напомню

Ссылка скрыта от гостей

- 6гигабит/с, а SATA2 может "просадить" весь потенциал SSD

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

и вот мы подошли !

Есть ли у кого-то опыт использования Лотусовых баз на сервере на SSD-дисках?

у мя есть опыт использования в др. применениях, но для домины имеет смысл (с перечисленными выше оговорками)