Как стать автором
Обновить

Комментарии 110

Надеюсь, они хостятся у VDSinы!
и во сколько обойдется такой сервер?
Примерно подобрал по ссылке на сервер выше конфигурацию.
Вышло чуть меньше 200к$

13 млн руб? Или 1.3млн?

Оба мимо :)
Гугл сказал, что это около 15 млн руб (российских)
Дорого… очень дорого :)
Примерно посчитать можно у европейских производителей. У наших не знаю кто ценники пишет сразу на таких терминаторов, обычно под заказ.
Миллионов пол 5 наверное… не меньше думаю.
то в конце концов Let's Encrypt пришлось бы разбить одну БД на несколько, но проведённый апгрейд позволил этого избежать.

Позволил избежать на некоторое время. Бесконечно расти вертикально невозможно, рано или поздно придется дробить.

А где в статье хоть словом упомянут вертикальный рост? Замена сервера на более мощный — не то же самое, что и вертикальное масштабирование.

ru.wikipedia.org/wiki/%D0%9C%D0%B0%D1%81%D1%88%D1%82%D0%B0%D0%B1%D0%B8%D1%80%D1%83%D0%B5%D0%BC%D0%BE%D1%81%D1%82%D1%8C
Вертикальное масштабирование — увеличение производительности каждого компонента системы с целью повышения общей производительности. Масштабируемость в этом контексте означает возможность заменять в существующей вычислительной системе компоненты более мощными и быстрыми по мере роста требований и развития технологий. Это самый простой способ масштабирования, так как не требует никаких изменений в прикладных программах, работающих на таких системах.

Замена сервера на более мощный — самый типичный пример вертикального масштабирования.

Бесконечно расти вертикально невозможно
А всегда ли нужно расти бесконечно?
А всегда ли нужно расти бесконечно?
Чтобы справляться с всё время возрастающей нагрузкой есть много выходов. Например перестать привлекать и обслуживать клиентов.
Самый часто используемый не железный — оптимизация софта, но тут тоже есть физические и финансовые ограничения.
Другой вариант — переход на другой комплекс ПО, который даст 5-20% прироста.
Ещё можно применять репликацию, но тут происходит большой оверхед в данных.
Четвертый вариант — дробить сервер на шарды, чтобы одна часть интернета обслуживалась одним сревером — вторая на другом. Технологически, это сложней, чем кажется, ведь нужно всё предусмотреть, и научить кучку обращающегося ПО ходить на разные серверы, а также спланировать плавную миграцию (расслоение) с одновременной синхронизацией данных. Что в случае с нагрузкой let's encrypt довольно сложно.

Отвечая на ваш вопрос — расти можно сколько угодно, но каждый следующий шаг будет сложнеё предыдущего)
Не согласен, что 4 вариант сложнее. Дробление можно сделать по принципу "был один центр сертификации, стало два центра сертификации" — в таком случае вообще никаких проблем нет, будет два независимых сервера.
стало два центра сертификации
Для второго независимого центра как минимум надо поднимать всю инфраструктуру (и это не 1 пачка серверов), а как максимум — снова сертифицироваться у верхнеуровневых корневых центров сертификации, это процесс не на один год, со своими заморочками и регулярными аудитами.
вообще никаких проблем нет
Не каждый же день появляются поставщики SSL :)
Основной вопрос в том, существует ли вообще в мире эта «всё время возрастающая нагрузка».
Инфраструктура гугл, амазона и майкрософта будет наверное хорошим примером. Они все время запускают свои новые проекты + продают какой-то из ее слоев наружу, пока что все наращивая и наращивая обороты. Для них это действительно все время возрастающая нагрузка на данном этапе.
существует ли всё время возрастающая нагрузка
Любой проект чем дольше живет, тем больше растёт, тем больше пользователей у него появляется. Если проект не растёт, значит умирает. Вариантов «как было 100 пользователей, так ровно 100 и осталось» не бывает.
Но в какой-то момент количество пользователей дорастает до 7 млрд.
В этом моменте ты вероятно уже делаешь что-то еще, потому что у тебя есть деньги, инфраструктура и люди чтобы это что-то делать. И оно тоже растет.
количество пользователей дорастает до 7 млрд.
Если будет Internet Of Things будущего, то число может быть и больше.
Ну кол-во активных веб сайтов не особо растет
In 2016, the number of websites has almost doubled: from 900 million to 1.7 billion. However, the more reliable active website count was stable at around 170
Если не будет — то придумают еще какие то сертификаты.
Неспроста же эта компания к примеру — некоммерческая и выдает бесплатные сертификатов TLS… бесплатное — сыр в мышеловке — зачем то подсаживают всех, и там где надо и там где не надо.
Вот этот Хабр защищен сертификатов TLS 1.3. Вопрос — для чего? Что тут шифровать?
Причем сейчас если сайт не привязан к сертификату, то вообще сразу его кидают как опасный, даже если это просто статичный HTML.

Ну вот, к примеру, у меня при использовании мобильного интернета (Tele2) любой сайт с "просто статичным HTTP" редиректит на рекламу при первом нажатии на любую ссылку. А при использовании HTTPS такого "почему-то" не происходит.

Я, конечно, читал через строчку, но как понял из текста у них уже есть инфраструктура бд primary/secondary. может им просто надо добавлять ноды в инфраструктуру, чтобы на 1 ноду приходилось не так много клиентов… Вообще когда очень очень много простых запросов, у меня как то сразу думается не в сторону 1го мощного сервера, а в сторону множества маленьких ARMчиков

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

Ну у них же сертификаты имеют срок действия, т.е. их число вряд ли будет расти нелинейно
Количество клиентов обычно растёт.
Верно.
denistrushin если бы количество клиентов не росло, то и заменять сервер не пришлось бы, ведь сертификаты сами бы давно уже истекли. А значит и новости этой не было бы)
Как раз наоборот, одна из причин замены — это уменьшение времени отклика. Т.е. скорее всего кол-во клиентов стало падать и они и решились на замену, чтобы улучшить свой сервис
Кол-во активных веб-сайтов в мире не растет с 2016 года
Т.е. скорее всего кол-во клиентов стало падать


Это не так. У них есть график количества пользователей на сайте и он постоянно растет.

Не все сайты пользуются Let's encrypt. За последние пару лет стараниями производителей браузеров многие из существующих сайтов перешли и еще будут переходить на https.

Ну, с учетом запаса текущего (что с 90% до 25% нагрузка упала), глядишь через несколько лет у них получится перейти на какие-нибудь 128 ядерные машинки с зен4 и при этом получить какие-нибудь 2,5 от текущего.
EPYC 7742 (64 ядра) имеет 2.25GHz, но MAX BOOST такой-же 3.40GHz, как у EPYC 7542 (32 ядра).
Интересно, — его поставить, — будут результаты намного другие, и в чём можно проиграть, кроме финансов?
AMD
image
А зачем, если даже текущий вариант превышает их потребности с запасом как минимум в 2 раза?

А когда они из него все-таки вырастут (через несколько лет), к тому времени уже сменится еще два-три поколения процессоров и стандарт памяти и можно будет взять уже сервер на 128 ядерных процессорах (причем ядер существенно улучшенной архитектуры, т.е. с заметно большей производительностью на 1 ядро — на Zen-4 или даже Zen-5, вместо Zen-2 в текущих EPYC ) с DDR-5 памятью и PCI-e 5й версии. Еще в разы увеличив производительность в рамках единственного сервера.

Из которого они уже вообще врядли потом вырастут. Т.к. несмотря на понаписанное выше количество клиентов, которым нужны сертификаты шифрования не может расти бесконечно — всегда есть потолок. В последние несколько лет оно у них быстро росло в основном за счет активного увеличения занимаемой доли рынка, чем за счет роста самого рынка. Но она и так уже сейчас ЕМНИП в районе 30% от общего количества выдаваемых и используемых во всем Интернете сертификатов.
Дальше по числу клиентов расти будет уже просто некуда если не хотим получить ситуацию монополии, когда единственная компания контролирует практически весь рынок.
Чета у меня волосы на голове зашевелились от понимания того, что безопасность и работоспособность 235ти миллионов сайтов в интернете зависит от двух кусочков железа установленных не совсем ясно кем, «где-то», и, даже, без геораспределенного резервирования.
Страшно жить… даже если это работает на EPYC.

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


Мир вообще страшная штука =)

Я согласен, но, помимо этого, считаю, что такие риски, при обнаружении, надо стараться устранить.
А то, «тетя Маша» приболеет на неделю, а где-то в Африке кто-то погибнет от голода.

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

Во-первых, проблема будет только с: "ошибки API и таймауты при выдаче сертификатов".
А, во-вторых, как уже сказали ранее — дареному коню странно в зубы глядеть. Лучше помогите материально...

У меня своих сайтов с lensencrypt сертификатом нет, так что, для меня этот конь не дареный, а, скорее, навязанный через 235 миллионов сайтов в интернете к которым резко стало очень мало доверия. Появился соблазн запихнуть letsencrypt-овский мастер-сертификат в список недоверенных.
А денег я бы дал скорее на разработку его конкурента, т.к. все яйца в одну корзину класть — неправильно. У пользователей должен быть выбор.
У пользователя сейчас есть выбор как раз. Есть куча предложений на любой бюджет.
Lets Encrypt пытается решить проблему для тех, у кого бюджета нет совсем. Что бы быстрее перевести интернет на https.
Т.к. пользователей с полностью отсутствующим бюджетом неожиданно оказалось настолько много, думаю, будет неплохо, если у них тоже будет выбор)
Они могут использовать сертификат хостера. Тоже вариант.
Некоторые DoS защиты и балансировщики предлагают такое даже с бесплатным планом. Вот ещё вариант.
Это все не то… у хостеров и сервисов ддос защиты, — это не «бесплатные сертификаты» а, скорее, способ сделать вендорлок.
Нужен прямой конкурент, который бы работал абсолютно аналогично, и настраивался как и letsencrypt просто заменой URL сервиса выдачи сертификатов.
Ну так в чём проблема? Хотите сделать конкурента — делайте. Вам спасибо только скажут.
Не считаю себя достаточно квалифицированным, чтобы этим заниматься. Тут нужен как минимум эксперт по ИБ экстра-класса.
А, вот, денег бы на это дал, хоть и не много.
Для некоторых настройка certbot'а — это уже слишком высокий порог вхождения и серт от хостера будет намного проще.
Только это не вендорлок, так как можно всегда уйти к другому хостеру, у которого будет то же самое ничего не потеряв. С таким успехом можно Letsencrypt назвать вендорлоком.
Если надоел CloudFlare, то можно завести свой сертификат. На работоспособность сайта это не скажется.
А если я сам себе хостер? Настройка certbot'а под виндой вообще простое дело — запустил, ввёл что ему надо, получил сертификат. Он еще и в автозагрузку сам пропишется что бы сертификаты обновлять. Потом только в конфиге Апача вписать пути к этим сертификатом и готово.
Это не важно кто кому хостер. Я про то, что если хостер даёт сертификат, то это ещё не вендорлок.
Если хостер даёт сертификат — надо брать и не дурить себе голову. Let's Encrypt и certbot созданы для других случаев.
И как это "не важно кто кому хостер"? Если я сам себе хостер(физлицо), то сертификат я себе дать не могу — я же не центр сертификации. Нужно искать где сделать сертификат. И Let's Encrypt с certbot — очень не плохой вариант.
Где такие ограничения, что нельзя давать себе сертификат?
Именно что не центр сертификации, а просто хостер. Не вижу как физлицо или юрлицо влияет на это.

Про certbot я уже написал выше. Для некоторых это может быть сложным шагом.
Не так написал — не просто физлицо, а дома и на домашнем интернете c "cервером" в подвале. Есть сайтик, толку от него нет, но пусть будет. Хостер хочет 320 баксов за за три года за хостинг — как-то дорого платить. Так почему бы самому не захостить? Тем более что интернет достаточно быстрый: Download 431.46 Mbps, Upload 525.54 Mbps по speedtest'у только что проверил. А постоянно включенный комп в подвале всё равно планирую для NAS и VPN(для доступа к этому NAS извне). Пока осваиваюсь — разобрался как под виндой всё сделать, теперь хочу разобраться как всё поднять на виртуальной машине с Ubuntu 20.04 Server.
Это к моему сообщению не имеет отношения.
Я говорил про возможности LE и просто заметил, что порог вхождения не такой уж и простой.
Хостинг в подвале никак на это не влияет. И уж точно никак не ограничивает получения сертификата.

А 320 за colo на три года — это очень хорошая цена на самом деле (даже в штатах). Я плачу за каждый свой сервер порядка $100/месяц в зависимости от ДЦ (интернет, конечно, быстрее полу-гигабита).
Надо брать за 320, там одно электричество будет близко к тому.
Электричество всё равно потратится, потому что VPN и NAS. Если будет ещё виртуальная машина с сервером — сильно счёт за электричество не увеличится.

"Где такие ограничения, что нельзя давать себе сертификат?" Ну как бы как минимум каждый браузер будет ругаться на левый сертификат… Если я вас правильно понял...

Я про хостера, который может выдать сертификат клиенту.
«Левый сертификат» — это когда само-подписанный, а не выданный самому себе. Наверно, из-за этого путаница получилась.
Если хостишь сам у себя(то о чём я говорил) то нет "хостера, который может выдать сертификат клиенту" и можно только выдать самоподписанный.
Можно выдавать чужой сертификат даже если сам хостер, так как есть полный доступ на сайт.
Разве сертификат не выдаётся на конкретный хост? И если сайт, на который зайти, выдаст чужой сертификат, разве браузер не будет ругаться на несовпадение?
У хостера есть доступ, что бы это сделать самому. Например, CloudFlare генерирует свой сертификат для сайта клиента. Там будет сертификат с правильным CN/SAN и потому браузер ругаться не будет.
Ходим кругами. Я заканчиваю.

P.S. минус вам не я поставил — видно не я один подметил что с вами дискутировать бесполезно.
Я не дискутирую, а просто объяснил, что сертификат может выдавать хостер. И привёл пример.

Не совсем понял по поводу минуса. При чём тут это? Я ведь никого не обвиняю в этом. А если вдруг показалось, что где-то обвинил, то я не говорил про минусы.
«Дискутируем» мы только вдвоём, больше вроде никто не участвует.
Тем более, что мне без разницы на эти минусы, так как они ни на что не влияют в любом случае.
Никто не спорит, что хостер может выдать сертификат. Потому что либо хостер имеет свой центр сертификации, либо покупает сертификаты пачками по bundle прайсу у центра сертификации и сертификат уже заложен в цену хостинга, либо же берёт из бесплатно у того же Let's Encrypt. В любом случае это не ваша проблема — хостер всё делает за вас.

Другое дело, когда такого хостера нет. Тогда либо покупать сертификат за деньги по Retail прайсу, либо брать бесплатно у того же Let's Encrypt.

Проблема в том, что в этом обсуждении две этих разных ситуации смешаны в кучу.
Проблема в том, что в этом обсуждении две этих разных ситуации смешаны в кучу.

Верно. Потому я уточнил выше, о чём я.
Но сейчас это уже не так важно, так как мы уже давно потеряли нить обсуждения и теперь непонятно о чём говорим.
Я говорю про сертификаты от хостера, которые клиентам заменяют LE. А Вы говорите про Windows и возможность добавить Ubuntu 20.04 у себя дома.
Надо пойти подышать свежим воздухом. Или машину из под снега раскопать. Пойду икать лопату…
Я не знаю, чего сложного в настройке базовых вариантов (а они по большому счёту и нужны большинству) через certbot. Зашел на сайт, выбрал ось, выбрал сервер, который крутится, ctrl-c/ctrl-v, enter, выбрал домены, ввёл инфу для сертификата, подтвердил, что да, поправь мне конфиги, далее в cron/как_там_в_systemd закинул строчку, которую выдало и телемаркет, сиди и наслаждайся, главное оплату сервера и домена не пропустить, а то сам сайт сдохнет.
Вполне нормально, что для кого-это может быть сложным. Например, они знают как на Wordpress обновления контента делать, а остальное уже требует консоли так или иначе. У всех разный опыт поддержки сайтов.
Разве что если хостер что-то по этому поводу сделал.

При чём тут не пропустить оплату сервера и домена? Это к сертификатам не имеет отношения. Не говоря уже о то, что обычно оплата сделана автоматом, что бы не следить за этим. Разве сейчас кто-то делает это вручную на постоянной основе?
Ппоблемы тех «у кого бюджета нет совсем» отлично решались и до появления Let's Encrypt. Еще совсем недавно можно было получить бесплатный сертификат на 3 года, установить и забыть. Но продавцам воздуха это не понравилось, поэтому появился Let's Encrypt и срок бесплатных сертификатов сократился до 3-х месяцев.
Где можно было получить? И почему нельзя получить сейчас?
И какая проблема с сертификатом в 3 месяца? Настраиваете certbot и сертификаты будут обновлятся автоматом.

У StartCom. И "почему" спрашивайте у тех, кто решил их замочить.
Проблема очень простая: их надо менять в 4 раза чаще. И меня вполне устраивало получать сертификат бесплатно и переставлять ручками раз в год, сейчас приходится делать то же самое, только за деньги.
Как быть, если я не хочу тащить к себе на сервер фиг знает кем написанное ПО, которое получает сертификаты с загруженных на 90% серверов очередной "корпорации добра"? Ну а свой клиент написать лень, да и сертификат пока стоит 2 евро в год.

Если хочется бесплатные сертификаты, то есть другие альтернативы. Например: https://habr.com/ru/company/globalsign/blog/529698/


А на код непонятно кем написанного ПО можно посмотреть и понять что оно делает. Благо одна из реализаций написана вообще написана на чистом sh.

У пользователей должен быть выбор.

Он есть — бесплатные сертификаты раздают ещё как минимум две компании — BuyPass и ZeroSSL, хоть и не совсем полные эквиваленты LetsEncrypt (с ограничениями и без wildcard), но их достаточно в большинстве случаев.


Относительно недавно на хабре уже была статья на эту тему.

По вашему для каждого сайта обязательно нужно платить «дань» за SSL иначе это не выбор? Странное у вас восприятие мира. lensencrypt используют во основном «домашние» сайты, более мение серьезные сайты все равно покупают ssl так же как и раньше
Странные вы делаете выводы. Я совсем о другом вообще-то. А именно, о возможности иметь запасной сервис, чтобы все эти домашние сайты не испарились в одночасье если с letsencrypt что-то случится. Там же не только технические риски, но, еще и разного рода организационные и юридические есть.
А то, что я готов пожертвовать на подобную инициативу денег, — совсем не значит, что я готов платить выдуманную вами «дань за SSL».
lensencrypt используют во основном «домашние» сайты, более мение серьезные сайты все равно покупают ssl так же как и раньше

да я бы не сказал, видел сертификаты от LE на сайтах с сотнями тысяч уников в сутки.

Не нравится — идёте в любой платный центр сертификации о получаете сертификат там. Основная идея Let's Encrypt'а — дать возможность получить сертификат бесплатно, что бы те(такие как личный блог с посещаемостью 3 человека в год), кто использовали незащищённое соединение могли перейти на защищённое соединение.
Кстати, а как именно связано доверие к центру с железом на котором этот центр работает? Я вот связи не вижу.
Приходит в голову Certificate revocation list. Может, ещё для чего-то.

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

Быстро_Дешево_Качественно.jpg

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

habr.com/ru/post/455236
от двух кусочков железа установленных не совсем ясно кем,


Вполне ясно кем, если Вы в теме. Посмотрите на страницу спонсоров. На одних спонсорах они получают около 5 млн $ год.

Там есть геораспределённые слейвы которые при падении мастера занимают его место. Просто шардинга нет.


Как начнут упираться в мастер — прошардятся через какой-нибудь Vitesse прозрачно для приложения и дальше поедут.

Та всё там нормально.

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

А ещё умные люди безоговорочно верят любому, кто скажет, что умным людям что-либо делать не положено.

У них есть репликация БД на независимые распределенные сервера, которые обрабатывают запросы на чтение. Это только primary сервер.

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

Единственно, что нельзя будет получить новый сертификат, пока главный сервер не работает. Т.е. либо спокойно дождаться восстановления его работы (если сроки позволяют) ну или получать сертификат в другом центре, если надо вот «прям срочно, а еще луче вчера» (например как раз проворонил плановую замену и текущий сертификат УЖЕ протух по сроку действия — но это уже админ сайта ССЗБ).
Что-то совсем непонятно насчёт потоков воздуха на процессорах, и куда дальше этот воздух уходит. Создаётся впечатление, что шлейфы за процами сильно этому мешают.
А что им там дальше за процессорами охлаждать? БПшки? В них свои кулера стоят.
Скорее всего в кадр не попали еще воздуховоды, которые потом накрывают сверху материнку и перераспределяют воздушные потоки
Такие например
image
Да нет, я не об охлаждении БПшек волнуюсь, а об отведении горячего воздуха от процов.
А, ну так в ЦОДе не стоит задача поставить низкооборотистую noctua для бесшумной работы. Там мощей кулеров хватает чтобы проталкивать поток из холодного коридора в горячий несмотря на все шлейфы и неоптимальные повороты с турбулентностью. Ну и холодный коридор достаточно холодный чтобы задавить всю эту неоптимальность хорошим перепадом температур
А, понятно, значит мои опасения насчёт неэффективности этих кулеров и расположения подтвердились.
Это еще 2U сервер — сверху кажется, что места мало, а на самом деле достаточно. Но даже в 1U проблем с продувкой нет — у меня есть несколько таких кулеров, 40x40 мм, длина около 50 мм, при этом на самом деле там два соосных кулера вращающихся в разные стороны, у первого кулера 5 лопастей, у стоящего за ним — три. Заявленный ток — 1.9А. И воет, и дует будь здоров. И это только один, а там их целый ряд…
Про Эпики еще добавлю, что они классные. Рабочую машину для домашней лаборатории собрал себе на нем…
Думал Тредриппер использовать или Xeon какой-нить, но 8 каналов памяти, 128 линий PCI-E 4.0, отсутствие чипсета (вместе с узким местом в виде DMI), возможность установки в одну материнку/сокет разных процессоров от 8ми до 64х ядер трех разных поколений (включая пока еще недоступный Milan), и, наконец, возможность купить все это прямо сегодня и сейчас, а не завтра, — победили.
Жалко только, что не разгоняется.

P.S. Надеюсь, что минусы от поклонников Intel будут сопровождаться комментарием с объяснением, где я не прав.
Спасибо пацанам! От души душевно!
Два серебристых прямоугольника посередине — процессоры

ох


На левом краю фотографии — 24 диска NVMe, такое возможно только на EPYC

нет, конечно же, pci-e switch давно придуманы и используются. или, например, SAS3416 позволяет в 8 линий pci-e подключить 4 накопителя с интерфейсом pci-e 4x.


Как один из вариантов рассматривался программный RAID (mdraid в Linux), но разработчикам посоветовали OpenZFS. Они решили попробовать, и вполне удовлетворены результатом.

интересны детали, сравнивали ли они поведение zfs и mdraid.

нет, конечно же, pci-e switch давно придуманы и используются. или, например, SAS3416 позволяет в 8 линий pci-e подключить 4 накопителя с интерфейсом pci-e 4x.
А потом попробуйте выжать с этих четырёх накопителей полную скорость. Если нагрузка равномерная — можно просто их подключить по две линии каждый и не нужны никакие "pci-e switch". Как по мне — эти самые pci-e switch вообще маркетинговая чепуха особенно для видеокарт. Если загружена только одна видеокарта — так и ставьте одну на PICe 16x. Если загружены две видеокарты — так и ставьте на 2x PICe 8x. PCIe switch магическим образом их x16 не сделает два по x16.
Есть нюанс. 4x PCIE gen 4 как раз таки магическим (на самом деле нет) способом превращается в 8x PCIE gen 3. Используется это, например, как раз для уплотнения SSD, когда в PCIE gen4 втыкается 2x gen3 ssd.
А потом попробуйте выжать с этих четырёх накопителей полную скорость

а что такое «полная скорость»? у pci-e 3 4x это 4 гигабайта в секунду.


;)

вот, предположим, типичный областной центр, у провайдера 100 тысяч абонентов с тарифом 100 мегабит в секунду. вы предлагаете провайдеру взять аплинк в 10 терабит в секунду?


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

да, тоже вариант. правда, свитч может обеспечить коэффициент и больше, чем 1:2

Жаль, что не написали, сколько именно серверов
Но, вцелом, интересно, зачем вообще использовать реляционную базу для подобных задач? Как я понимаю, скоуп запросов жестко фиксирован, запросы от разных клиентов независимы. Соответственно, возникают вопросы, нужен ли там b-tree, или хватит хеш таблиц, нужен ли синхронизированный по всем клиентам WAL, и так далее. Реляционные СУБД, все же, швейцарский нож. Может, тут скальпель нужен?
Реляционные СУБД, все же, швейцарский нож.


Да. Но реляционку можно вполне искользовать как no-sql.

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

Но идея, вцелом, не очень хорошая для таких нагрузок и таких задач.


Почему? Реляционки дадут фору многим но-скл решениям (которые не in memory only).

Реляционки тратят слишком много ресурса и требуют слишком много от железа, давая взамен фичи, ненужные продукту.


Это не так. Реляционка, например постгрес, на дешевой виртуалке за 5$ легко потянет 1000 рек-сек без особых проблем, если запросы вроде where id = x и есть индес по id.

>Реляционка, например постгрес, на дешевой виртуалке за 5$ легко потянет 1000 рек-сек без особых проблем


Охотно верю. В моем опыте были проекты с миллиардами событий в день как на постгресе, так и на MS Sql Server. Правда, понятно, что оборудование там было близкое к описанному в статье)


>Почему? Реляционки дадут фору многим но-скл решениям 


Потому, что
1) они отвратительно масштабируются. В примере в посте разрабы не хотят головняка с независимыми шардами, поэтому держат всю базу одним куском и реплицируют ее целиком. Это очень плохой паттерн, ибо
1.1) производительность системы ограничена скоростью записи мастера и скоростью воспроизведения WAL на самом медленном слейве, а ограничение по объему = объем самого маленького слейва
1.2) слейвы делают огромный объем работы впустую. К примеру, по нагрузке на процы, надо 10 слейвов. В случае no-sql решений можно шардировать данные так, чтобы каждая из 10 машин содержала лишь 1/10 всех данных. Тут же так не выйдет. Каждый слейв вынужден оперировать объемом данных в 10 раз большим, чем минимально возможный. Сюда еще в 10 раз большее время восстановления из бекапа и прочие радости
1.3) шардинг реляционок возможен, но он лишает их практически всех плюсов перед no-sql собратьями
2) они делают много работы впустую. Огромная инфраструктура, связанная с WAL, транзакциями, консистентностью, MVCC, корректной инвалидацией кешей тратит процессорное время, IO, память. Если это обусловлено задачей (к примеру, клиент А перевел клиенту Б деньги, и ситуация, когда деньги задвоятся или обнуляться, недопустима для бизнеса), то это оправданная цена, но для управления сертификатами непонятно, зачем

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

Как я понимаю, чтобы реализовать один и тот же высоконагруженный сценарий, то для кассандры потребуется в разы меньше дисков и памяти.
Условно, есть база на 10ТБ постгресс, требующая 10 реплик для чтения, чтобы выдержали процы. То есть, нам надо иметь 110ТБ NVMe дисков + память под это все дело. И мы в итоге получаем систему с репликейшн лагом и нетривиальными процедурами восстановления работы при падении мастера.
В случае кассандры же, нам достаточно 30ТБ NVMe, сильно меньше памяти (да, в 2 раза больше камней, увы), но, зато, система практически неопрокидываема от отказа железа и нет репликейшн лага

У касандры с памятью проблемы. Например, ее невозможно поднять на том же 5$ инстансе, на котором постгрес легко держит 1000 рек-сек. Сколько она будет использовать при большой лоаде не могу предсказать. Нужно тестить, конкретный сценарий.
1.3) шардинг реляционок возможен, но он лишает их практически всех плюсов перед no-sql собратьями

из ваших слов выходит, что если мы можем шардить, то реляционные бд примерно на уровно nosql. если не можем — то реляционные без вариантов.


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


я не спорю, nosql имеет свою нишу, но в 99% обычный sql банально удобнее/привычнее, а такого уж прямо highload'а нет

Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.