Артем: Статья при том, что SSD надёжнее HDD. В связи с этим риски использования страйпа уменьшаются. У нас в офисе 4 гипервизора с HDD и SSD (для Dev). Вообще страйп на ssd было не моим решением, это было уже когда я пришёл в эту контору. Я как админ был против, но вот уже более полутора лет как всё работает и есть возможность восстановить нужные VPS при необходимостия. Делаются регулярные бэкапы репозиториев с проектами и другими частями инфраструктуры.
Насчёт глюка контроллера - ну всё может быть. Что уж тут паниковать раньше времени. Если так задуматься то завтра может прилететь астероид и грохнуть жизнь на Земле ))) - какой смысл тогда вообще жить? )))
Не придумывайте проблемы если их нет.
Артем: Используем вполне нормально. Ну отвалятся. Это вм для Dev, поэтому это не сильно критично. К тому же все проекты разворачиваются из единого репозитория который лежит уже на зеркале. + на гипервизоре есть ещё и HDD, что позволяет поднять новые копии упавших виртуалок, а потом уже разбираться с разбитым страйпом.
Так что всё вполне в приемлемых рамках.
Стоит вспомнить свежую статью про тест SSD. Показательно я д умаю. Вряд ли HDD так же будут работать с такой же надежностью.
На самом деле ничего ужасного. Тут есть просто необходимость делать регулярные бэкапы.
К тому же SSD диски гораздо надёжнее HDD, так что вероятность проблем существует, но минимальней чем при использовании HDD в такой конфигурации.
У нас так в RAID используются диски для виртуальных машин. Т.е. это хранилище гипервизора. Главное что бы было возможно нужную инфу восстановить (из бэкапа) в случае аварии, а остальное уже мелочи.
+1 к ответу.
по моему вполне конкретно написано:
servers using encryption technology in Internet transactions
могу перевести: Сервера использующие крипто технологии в интернет транзакциях (ssh, ssl, vpn), но скорее всего SSL для WWW
un1t: нет, там руками задаёшь количество шардов. В конфиге. И количество реплик. Ставь эластик из репы их и конфиг там хорошо документирован - очень сложно не разобраться.
из плагинов сразу ставь kopf и HQ - самые оптимальные на наш взгляд.
В эластике при падении одной из нод все шарды распределятся по оставшимся - автоматически. Самая главная проблема - количество реплик шардов. Например у нас было так: 4 ноды. 1 реплика шарда. При падении 2-х нод из 4-х у нас велика вероятность того, что часть шардов окажется только на этих двух упавших нодах. В итоге так и случилось. Увеличили количество реплик и радуемся.
И в эластике всё практически автоматом. Там ничего сугубо серъёзного придумывать не требуется - только конфиг настроить.
"Еще монга schemaless, в эластике надо указывать mappings."
Боюсь у вас тут заблуждение. mappings указывать далеко не обязательно, насколько я понял из документации. Эластик сам определяет типы. Да и вот (db-engines.com/en/system/Elasticsearch%3BMongoDB) нашёл сравнение, но там тоже shema-free
Stan_1: по моему 100-150мс ни о чём
у нас Search - Query: 463.5ms 460.46ms 489.78ms 526.43m
4 ноды в кластере. Правда у нас за 100 миллионов документов, объём индекса около 12 гигабайт. На каждой ноде по 50 гигов оперативы, в HEAP выделено по 30гигов. Для хранилища используются диски SSD.
У нас очень тяжёлые запросы идут на него потому такие задержки. Когда было 2 ноды получалось держать всего 40-50 миллионов документов.
ИМХО пока что не вижу нужды сильно заморачиваться. Попробуйте кластер - это должно уменьшить время запросов. Для кластера и машинки можно с меньшим объёмом памяти брать.
HDD для хранилища даже не рассматривайте - Elastic очень чуствителен к IO
Да, ещё обратите внимание на mappings - выставьте корректные типы данных - нам позволило это сократить индекс в 6,5 раз от первоначальных результатов.
Укажите при проверке назначать ярлык.
и ещё проверьте не стоит ли случаем галочка " Архивировать входящие письма (пропустить входящие)" - может из-за этого.
