Новая тема   Ответить

 S_Flash
На сервере установлен SAS диск и SSD. SAS, естественно, больше по обьёму. Система на SAS, вебсервер смотрит на www, которая на разделе SSD.

Задача такая: На SAS есть директория www которая зеркалируется на SSD. Т.е. работаем с файлами по FTP с дирой на SAS, а отдаём с SSD. (Бэкап решение на случай отказа SSD)

Основной вопрос в том, как сделать, чтоб контент совпадал с минимальным лэтенси на обоих дисках и при этом не загрузить ресурсы сервера на выполнение частого зеркалирования? Контент - пиксы, 1 000 000 - 2 000 000 штук.

 Tornado
построить зеркало SSD+ кусок SAS (не весь диск, а только его часть), но это скорее всего создаст проблему иного плана , а именно "съест" часть производительности SSD

либо использовать SSD в качестве кеша(bcache , EnhanceIO, либо как-то иначе), а подложкой будет SAS

 S_Flash
Tornado писал:
А как технически реализовать это зеркало? Всё, что я знаю, не затрагивающее файловую систему дабы избежать ториозов на низкоуровневом зеркалировании - это rsync, но его основная проблема - это задержка между синхронизациями и неизвестно как он будет "тормозить" ФС при сопоставлении копий 1 000 000+ файлов.

 Tornado
используйте md-raid

важно: сделайте бекап данных!
например, что-то вида mdadm -C /dev/mdN --level=1 --raid-devices=2 /dev/sda3 /dev/sdb
где sda3 партиция с размером равным размеру ssd
/dev/mdN - имя создаваемого массива (должно быть уникальным)

незабудьте внести настройки в mdadm.conf
и после этого создать файловую систему поверх md-устройства и влить в него данные.

в зависимости от опыта и желания некоторые шаги могут быть изменены.

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

либо можно "развернуть" логику работы с данными, и записывать и отдавать данные сразу с SSD, а на SAS синхронизировать как бекап.

 S_Flash
Спасибо за интересную инфу!

Скорее, логика работы с данными мне ближе, так как вариант бэкапа приследуется первым. Но я считаю, что данные в нативном состоянии должны попадать сначала на SAS, так как в теории он я вляется более надёжным (согласен, что не факт), а уже после этого попадать на SSD. В такой последовательности, на случай, если SSD выхордит из строя первым, а данные продолжают попадать на SAS, то в промежутке, выявления проблемы и переключения на бэкап, поступающие данные остаются целостными на 100%, а во вторых, такой вариант гарантирует невозможность копирования поврежённых данных с вышедшего из строя SSD, в отличие от того, когда данные поступали бы на SSD первым.

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

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

 Tornado
S_Flash: А почему Вы уверены что SSD вылетит первым? У нас есть клиент который на свой сервер на colo поставил SSD HDD еще (если не ошибаюсь) в 2012 году - мы как раз помогали ему в их приобретении в штатах. Так вот - проблем с винтами не было и замену этих винтов мы не производили.

На своих серверах баз данных мы используем SSD диски уже более года - проблем не было.

Можно долго спорить о долговечности SSD - но ведь ни один вид дисков не застрахован от поломок, будь то SSD или SAS или SATA.

Поэтому правильно отмечает EvGenius - зеркало сайта оптимально держать на другом сервере и в другом дата центре

 color
Не проще ли работать с SSD как с основным, и с него же бэкапить периодически куда надо?

 DiamonD


+1 тем более что в 99% случаев вылетает контроллер ssd, а не сама память. При этом данные остаются доступными на чтение.


Оффтопик: PS. Но лично я бы тумбы держал на больших SATA в raid и отдавал их в CDN :-) В данном случае вообще пофиг на сервер-хранилище тумб. Хоть он пусть валяется месяц, тумбы будут отдаваться из кеша CDN :-)

 S_Flash
Может и проще, но с точки зрения целостности информации не верно. Если только не пренебречь какой-то её частью.
В тот момент пока винт вылетит, если это будет SSD, то часть инфы продолжит отправляться на поломаный HDD и соответвенно на момент замены потеряется.

ПС Хостерам всегда лиш бы проще, а то, что потом часть статики будет битая, это проблемы клиента!

 div
можно zfsonlinux поставить, ежели смелый. если фря - там zfs более-менее нормальная

а потом SSD как l2cache и как раз твоя задача решена

 color
тоже вариант, тоже используем такое - полет нормальный

 DiamonD
S_Flash писал:

Лично для себя сделал так:
Система и домены - 2 SAS в зеркале, 2 SSD отдельно обрабатывают свои задачи (один MySQL, другой сфинкс, мемкеш). Базы бэкапятся на SAS и отдельно на клауд. Статика с отдельного сервера, где 12 SATA дисков в 6 рейде, кешируется в CDN.
Не знаю что тут должно поломаться, чтобы рвать волосы на голове.. Только если сервак целиком сгорит. Но и для этого есть решение, можно сразу же прописать cname для домена и отдавать морду с CDN, пока меняешь материнку (это в теории, на практике, 3 тьфу, за 10 лет до такого не дошло)..