Если это действительно так, то берете SLA вашего провайдера и смотрите сколько вам стоит даунтайм (у ipserver 99.9 https://uptime.is/99.9 - могут лежать по 43 минуты в месяц и это, кстати, неплохой показатель; у селектела 99.8 например - это полтора часа в месяц)
Дальше смотрите сколько стоит ваш хостинг и строите резерв у другого хостера в другом датацентре (лучше даже с разнесенной географией, на случай больших проблем).
То есть, просто надо принять как факт что вероятность отказа датацентра всегда существует.
А дальше считать что выгоднее - переждать даунтайм или быть к нему готовым, но иметь более высокие эксплуатационные расходы.
PS> У нас есть сервера и в селектеле и в ipserver и ещё много где и мы резервируемся в две дополнителных локации не считая резервов внутри площадки (отказ стойки нам не страшен вообще). Восстановление полной функциональности с потерей данных в пределах единиц секунд занимает в зависимости от сценариев отказа: 5min, 30min, 6hrs.
При этом мы считаем допустимым аптайм до 99.7, хотя фактически кружимся вокруг цифр 99.95-99.99.
https://ru.hetzner.com/hosting/produkte_rootserver/ex51ssd-gpu/
дешевле не видел
И в dmesg ещё
У нас в работе суммарно 850х (pro/evo) было около 40 штук на всех серверах.
Они не сдохли - это правда. Прошки приняли неплохой объём записи - до 900тб за ~ полтора года.
Начали делать reallocate и были заменены вместе с платформой. На эво мы проработали чуть меньше полугода и сменили платформу ещё раз из-за производительности ниже плинтуса.
Кому-то оно может и подойдёт, но только я с тех пор техподдержку пытаю до классов/моделей дисков. Либо требую подтверждения enterprise class.
Потому что десктоп в серверах с более-менее стабильной нагрузкой - не алё.
PS. За 4 года 850 линейка сменилась на 860; 850 было несколько поколений (в evo). Они заметно отличаются между собой, хотя всё ещё "850".
Последнее время хреново там с качеством (судя по аптайму железа в старом дц МСК) - постоянные проблемы с сетью: просто просаживается скорость в один поток до 10-12 мегабит или пинги скачут до 1к+
давайте мы всё-таки будем точны: существует размер блока и глубина очереди
а также вопросы о буферизации (принудительном или отложенном sync при) записи
Дальше - чем больше блок и выше глубина очереди (при той же латенси), тем большую вы получаете производительность в KBps.
Латентность диска является ключевой, так как именно она показывает _сколько времени заняла операция_. Не суть важно какая и какого размера. И на какой глубине очереди.
Меньше латенси - больше успели сделать. Больше латенси - больше ждали завершения операции и меньше сделали.
Байты в секуду вытекают прямо из показателя латентности. Самый жёсткий способ проверить запись диска - пописать в него с принудительной синхронизацией и глубиной очереди 1 (=журнальный режим; fio --ioengine=libaio --sync 1 --direct=1 --name=test --bs=4k --iodepth=1 --readwrite=write --runtime 60 --filename=/dev/sdXX)
--
По поводу "шаринга" Pcie-lanes. Мне неизвестно как подобное может реализовываться. Pcie-lane используется в режиме "точка-точка". То есть соединяет напрямую устройства (либо устройство и коммутатор).
На любой матплате pcie-линии есть у процессора и у чипсета. (Сколько и каких - смотрите спеку чипсета и проца соответственно).
Дальше начинаются детали. Иногда разъёмов распаяно больше, чем у нас умеет система. Это значит что линий в разъём подано меньше (и в х16 разъёме 4 линии или даже одна) или же есть Pcie-hub (он же - коммутатор).
Соединение проц-чипсет занимает линии. Соединение проц-память также занимает линии. Коммутатор - это отдельная микруха, которая стоит денег. Просто так её никто не ставит.
И дальше есть вопрос топологии - не все линии одинаково полезны (линии от процессора с ТЗ процессора лучше, так как меньше задержка) а самые "плохие" - линии из хаба, потому как до процессора (который данные и молотит) ехать дольше всего.
Но я на геймерских платах не видел хабов вообще :)
К какому коммутатору (устройству) подключен какой разъём - есть вопрос. Каждый производитель решает это по-своему.
Соответственно, можно стать жертвой маркетолога и использовать х16 дырку в режиме х1 - но это значит что кто-то не ходил в биос и не настраивал ничего и хорошо бы почитать матчасть :)
С м.2 налажать по линиям невозможно.
я так подозреваю, 970про такое выедает только в синтетических тестах с адской глубиной очереди и большими блоками и очень недолго :)
960про тоже вроде был кошерный и классный, только нифига под боевыми нагрузками не мог
в ЕХ свежих стоят MSI Z370 Gaming
декстопные процессоры от интелов не умеют Pcie старше 3.0 (смотри ark) и несут всего по 16 линий Pcie в процессор, z370 ещё нормально добавляет (+24 линии)
Думаю, что даже там всё будет работать нормально :)
Промышленный U.2 реализует также 4 линии pcie (как и любой типовой nvme-диск), и пока почему-то даже интелы на дорогущих мамках под много xeon scalable это не меняют, хотя туда втыкают как раз правильные и дорогие p4600.
Даже там в bandwidth не упираются.
Всё потому что NVME ценнен показателями tps и латентностью в первую очередь.
Не гигабайты в секунду надо сравнивать)
Зависит от времени теста. На коротких тестах в минуту-две они себя показывают молодцами.
На долгих тестах всё зависит от характера нагрузки (write-тесты весь десктоп не сливает и это нормально) и качества охлаждения тестового стенда.
По опыту работы с хайлоад проектами (2k+ rps в бэкэнды) - там очень разнородные данные и куда как важнее качество сети внутри кластера - чтобы не лагали десятки серверов мемкеша и всё такое :)
Но, да, на тех масштабах о десктопах речь не идёт и счет памяти в серверах БД идёт уже далеко не на десятки гигабайт.
На текущих проектах (до 500 rps) можно использовать декстопное железо, но это надо делать с умом. И это позволяет серьёзно экономить не выбиваясь из целевого аптайма.
Формально вы правы.
На деле же надо очень постараться чтобы повесить пару нвмех на Pcie-x4. Да и дисков (шта? они уже даже не круглые :D) которые Pcie-x4 в состоянии уложить в полку не очень много, стоят они серьёзных бабок и обычно ставятся в серверные платформы, где х4 линий хватает всем.
Другое дело что софтварный рейд из хороших NVMe портит одну из их самых вкусных и дорогих характеристик - низкую латентность, позволяя получить прирост bandwidth (ну и ещё и CPU потратить, ага).
Мы обычно не строим рейды, а собираем lvm поверх нескольких дисков - просто потому что от lvm нам никуда не деться из-за особенностей гипервизора.
Обратитесь к нормальным ребятам, которые понимают как строить инфраструктуру под быстроразвивающиеся проекты с серьёзной нагрузкой, получите от них консультацию за деньги и понимание того что вам в какой момент времени нужно.
А потом уже приходите искать хостера (возможно вам и подскажут даже к кому обратиться за железками-виртуалками).
А то вам тут щас продадут.
fio всё прекрасно показывает, зря вы так)
дешевые домашние nvme неплохо выдерживают долговременное чтение - на них отлично укладывать какие-нибудь большие и редкоменяемые куски кеша или "холодные" данные - например на intel 760p мы разложили шарды greenplum (чтения там много, запись же может и потерпеть)
но "для всего" и "под серьёзную нагрузку" решение плохое - тут даже спорить не буду
У нас один нагруженный сервер субд может нести в себе до трёх типов дисков:
1) intel optane или хорошие nvme (pm963, p4600, p35xx) - под wal и горячие данные
2) sata ssd enterprise (pm863, s3510) - под индексы холодных данных и тёплые данные
3) sata ssd desktop / nvme desktop (что найдётся) - под холодные или редкоменяемые данные