Comments 110
то в конце концов Let's Encrypt пришлось бы разбить одну БД на несколько, но проведённый апгрейд позволил этого избежать.
Позволил избежать на некоторое время. Бесконечно расти вертикально невозможно, рано или поздно придется дробить.
А где в статье хоть словом упомянут вертикальный рост? Замена сервера на более мощный — не то же самое, что и вертикальное масштабирование.
Вертикальное масштабирование — увеличение производительности каждого компонента системы с целью повышения общей производительности. Масштабируемость в этом контексте означает возможность заменять в существующей вычислительной системе компоненты более мощными и быстрыми по мере роста требований и развития технологий. Это самый простой способ масштабирования, так как не требует никаких изменений в прикладных программах, работающих на таких системах.
Замена сервера на более мощный — самый типичный пример вертикального масштабирования.
Бесконечно расти вертикально невозможноА всегда ли нужно расти бесконечно?
А всегда ли нужно расти бесконечно?Чтобы справляться с всё время возрастающей нагрузкой есть много выходов. Например перестать привлекать и обслуживать клиентов.
Самый часто используемый не железный — оптимизация софта, но тут тоже есть физические и финансовые ограничения.
Другой вариант — переход на другой комплекс ПО, который даст 5-20% прироста.
Ещё можно применять репликацию, но тут происходит большой оверхед в данных.
Четвертый вариант — дробить сервер на шарды, чтобы одна часть интернета обслуживалась одним сревером — вторая на другом. Технологически, это сложней, чем кажется, ведь нужно всё предусмотреть, и научить кучку обращающегося ПО ходить на разные серверы, а также спланировать плавную миграцию (расслоение) с одновременной синхронизацией данных. Что в случае с нагрузкой let's encrypt довольно сложно.
Отвечая на ваш вопрос — расти можно сколько угодно, но каждый следующий шаг будет сложнеё предыдущего)
стало два центра сертификацииДля второго независимого центра как минимум надо поднимать всю инфраструктуру (и это не 1 пачка серверов), а как максимум — снова сертифицироваться у верхнеуровневых корневых центров сертификации, это процесс не на один год, со своими заморочками и регулярными аудитами.
вообще никаких проблем нетНе каждый же день появляются поставщики SSL :)
существует ли всё время возрастающая нагрузкаЛюбой проект чем дольше живет, тем больше растёт, тем больше пользователей у него появляется. Если проект не растёт, значит умирает. Вариантов «как было 100 пользователей, так ровно 100 и осталось» не бывает.
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.
denistrushin если бы количество клиентов не росло, то и заменять сервер не пришлось бы, ведь сертификаты сами бы давно уже истекли. А значит и новости этой не было бы)
Кол-во активных веб-сайтов в мире не растет с 2016 года
Т.е. скорее всего кол-во клиентов стало падать
Это не так. У них есть график количества пользователей на сайте и он постоянно растет.
Не все сайты пользуются Let's encrypt. За последние пару лет стараниями производителей браузеров многие из существующих сайтов перешли и еще будут переходить на https.
Интересно, — его поставить, — будут результаты намного другие, и в чём можно проиграть, кроме финансов?
А когда они из него все-таки вырастут (через несколько лет), к тому времени уже сменится еще два-три поколения процессоров и стандарт памяти и можно будет взять уже сервер на 128 ядерных процессорах (причем ядер существенно улучшенной архитектуры, т.е. с заметно большей производительностью на 1 ядро — на Zen-4 или даже Zen-5, вместо Zen-2 в текущих EPYC ) с DDR-5 памятью и PCI-e 5й версии. Еще в разы увеличив производительность в рамках единственного сервера.
Из которого они уже вообще врядли потом вырастут. Т.к. несмотря на понаписанное выше количество клиентов, которым нужны сертификаты шифрования не может расти бесконечно — всегда есть потолок. В последние несколько лет оно у них быстро росло в основном за счет активного увеличения занимаемой доли рынка, чем за счет роста самого рынка. Но она и так уже сейчас ЕМНИП в районе 30% от общего количества выдаваемых и используемых во всем Интернете сертификатов.
Дальше по числу клиентов расти будет уже просто некуда если не хотим получить ситуацию монополии, когда единственная компания контролирует практически весь рынок.
Страшно жить… даже если это работает на EPYC.
С другой стороны, жизнь и возможность купить еду для миллионов людей в современном мире гипотетически може зависеть (и скорее всего зависит) от какой-нибудь тёти Маши из Арканзаса, которая с 199х года каждую неделю ручками в экселе сводит лежащие на древнем hdd таблицы одной ей известным способом.
Мир вообще страшная штука =)
Может если бы сертификаты были не совсем бесплатными (хотя бы подписка с флет-рейт) то у них было бы больше возможностей по резервированию, но пока это всё держится на энтузиазме и спонсорах — странно ожидать большего.
Во-первых, проблема будет только с: "ошибки API и таймауты при выдаче сертификатов".
А, во-вторых, как уже сказали ранее — дареному коню странно в зубы глядеть. Лучше помогите материально...
А денег я бы дал скорее на разработку его конкурента, т.к. все яйца в одну корзину класть — неправильно. У пользователей должен быть выбор.
Lets Encrypt пытается решить проблему для тех, у кого бюджета нет совсем. Что бы быстрее перевести интернет на https.
Некоторые DoS защиты и балансировщики предлагают такое даже с бесплатным планом. Вот ещё вариант.
Нужен прямой конкурент, который бы работал абсолютно аналогично, и настраивался как и letsencrypt просто заменой URL сервиса выдачи сертификатов.
Только это не вендорлок, так как можно всегда уйти к другому хостеру, у которого будет то же самое ничего не потеряв. С таким успехом можно Letsencrypt назвать вендорлоком.
Если надоел CloudFlare, то можно завести свой сертификат. На работоспособность сайта это не скажется.
И как это "не важно кто кому хостер"? Если я сам себе хостер(физлицо), то сертификат я себе дать не могу — я же не центр сертификации. Нужно искать где сделать сертификат. И Let's Encrypt с certbot — очень не плохой вариант.
Именно что не центр сертификации, а просто хостер. Не вижу как физлицо или юрлицо влияет на это.
Про certbot я уже написал выше. Для некоторых это может быть сложным шагом.
Я говорил про возможности LE и просто заметил, что порог вхождения не такой уж и простой.
Хостинг в подвале никак на это не влияет. И уж точно никак не ограничивает получения сертификата.
А 320 за colo на три года — это очень хорошая цена на самом деле (даже в штатах). Я плачу за каждый свой сервер порядка $100/месяц в зависимости от ДЦ (интернет, конечно, быстрее полу-гигабита).
Надо брать за 320, там одно электричество будет близко к тому.
"Где такие ограничения, что нельзя давать себе сертификат?" Ну как бы как минимум каждый браузер будет ругаться на левый сертификат… Если я вас правильно понял...
«Левый сертификат» — это когда само-подписанный, а не выданный самому себе. Наверно, из-за этого путаница получилась.
P.S. минус вам не я поставил — видно не я один подметил что с вами дискутировать бесполезно.
Не совсем понял по поводу минуса. При чём тут это? Я ведь никого не обвиняю в этом. А если вдруг показалось, что где-то обвинил, то я не говорил про минусы.
«Дискутируем» мы только вдвоём, больше вроде никто не участвует.
Тем более, что мне без разницы на эти минусы, так как они ни на что не влияют в любом случае.
Другое дело, когда такого хостера нет. Тогда либо покупать сертификат за деньги по Retail прайсу, либо брать бесплатно у того же Let's Encrypt.
Проблема в том, что в этом обсуждении две этих разных ситуации смешаны в кучу.
Проблема в том, что в этом обсуждении две этих разных ситуации смешаны в кучу.
Верно. Потому я уточнил выше, о чём я.
Но сейчас это уже не так важно, так как мы уже давно потеряли нить обсуждения и теперь непонятно о чём говорим.
Я говорю про сертификаты от хостера, которые клиентам заменяют LE. А Вы говорите про Windows и возможность добавить Ubuntu 20.04 у себя дома.
Надо пойти подышать свежим воздухом. Или машину из под снега раскопать. Пойду икать лопату…
Разве что если хостер что-то по этому поводу сделал.
При чём тут не пропустить оплату сервера и домена? Это к сертификатам не имеет отношения. Не говоря уже о то, что обычно оплата сделана автоматом, что бы не следить за этим. Разве сейчас кто-то делает это вручную на постоянной основе?
С таким успехом можно Letsencrypt назвать вендорлоком
Но у них же открытый протокол ACME, и можно быстро сменить провайдера, изменив в своих скриптах лишь настройки...
И какая проблема с сертификатом в 3 месяца? Настраиваете certbot и сертификаты будут обновлятся автоматом.
У StartCom. И "почему" спрашивайте у тех, кто решил их замочить.
Проблема очень простая: их надо менять в 4 раза чаще. И меня вполне устраивало получать сертификат бесплатно и переставлять ручками раз в год, сейчас приходится делать то же самое, только за деньги.
Как быть, если я не хочу тащить к себе на сервер фиг знает кем написанное ПО, которое получает сертификаты с загруженных на 90% серверов очередной "корпорации добра"? Ну а свой клиент написать лень, да и сертификат пока стоит 2 евро в год.
Если хочется бесплатные сертификаты, то есть другие альтернативы. Например: https://habr.com/ru/company/globalsign/blog/529698/
А на код непонятно кем написанного ПО можно посмотреть и понять что оно делает. Благо одна из реализаций написана вообще написана на чистом sh.
У пользователей должен быть выбор.
Он есть — бесплатные сертификаты раздают ещё как минимум две компании — BuyPass и ZeroSSL, хоть и не совсем полные эквиваленты LetsEncrypt (с ограничениями и без wildcard), но их достаточно в большинстве случаев.
Относительно недавно на хабре уже была статья на эту тему.
А то, что я готов пожертвовать на подобную инициативу денег, — совсем не значит, что я готов платить выдуманную вами «дань за SSL».
lensencrypt используют во основном «домашние» сайты, более мение серьезные сайты все равно покупают ssl так же как и раньше
да я бы не сказал, видел сертификаты от LE на сайтах с сотнями тысяч уников в сутки.
Кстати, а как именно связано доверие к центру с железом на котором этот центр работает? Я вот связи не вижу.
Если центр, как оказывается, экономит на железе, выжимая из него последние соки, то есть риск остаться без перевыпущенного сертификата в самый неподходящий момент.
Хотите минимизировать риск остаться без сертификата — можете заплатить немного денег и получить его с большей вероятностью.
Хотите бесплатно — принимайте риск неподходящего момента.
habr.com/ru/post/455236
от двух кусочков железа установленных не совсем ясно кем,
Вполне ясно кем, если Вы в теме. Посмотрите на страницу спонсоров. На одних спонсорах они получают около 5 млн $ год.
Там есть геораспределённые слейвы которые при падении мастера занимают его место. Просто шардинга нет.
Как начнут упираться в мастер — прошардятся через какой-нибудь Vitesse прозрачно для приложения и дальше поедут.
По ссылке о настройке OpenZFS пишут что есть и геораспределенная репликация, и ежедневные бэкапы.
Так что если даже с ним случится что-нибудь критическое, то ничего с этими 235 миллионами сайтов не произойдет, сертификаты останутся валидны и их можно будет проверить, шифрование данных продолжит работать, все запросы клиентов по сертификатам продолжат обрабатывать сервера с репликами БД.
Единственно, что нельзя будет получить новый сертификат, пока главный сервер не работает. Т.е. либо спокойно дождаться восстановления его работы (если сроки позволяют) ну или получать сертификат в другом центре, если надо вот «прям срочно, а еще луче вчера» (например как раз проворонил плановую замену и текущий сертификат УЖЕ протух по сроку действия — но это уже админ сайта ССЗБ).
Скорее всего в кадр не попали еще воздуховоды, которые потом накрывают сверху материнку и перераспределяют воздушные потоки
Думал Тредриппер использовать или 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.
А потом попробуйте выжать с этих четырёх накопителей полную скорость
а что такое «полная скорость»? у 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, память. Если это обусловлено задачей (к примеру, клиент А перевел клиенту Б деньги, и ситуация, когда деньги задвоятся или обнуляться, недопустима для бизнеса), то это оправданная цена, но для управления сертификатами непонятно, зачем
Как я понимаю, чтобы реализовать один и тот же высоконагруженный сценарий, то для кассандры потребуется в разы меньше дисков и памяти.
Условно, есть база на 10ТБ постгресс, требующая 10 реплик для чтения, чтобы выдержали процы. То есть, нам надо иметь 110ТБ NVMe дисков + память под это все дело. И мы в итоге получаем систему с репликейшн лагом и нетривиальными процедурами восстановления работы при падении мастера.
В случае кассандры же, нам достаточно 30ТБ NVMe, сильно меньше памяти (да, в 2 раза больше камней, увы), но, зато, система практически неопрокидываема от отказа железа и нет репликейшн лага
1.3) шардинг реляционок возможен, но он лишает их практически всех плюсов перед no-sql собратьями
из ваших слов выходит, что если мы можем шардить, то реляционные бд примерно на уровно nosql. если не можем — то реляционные без вариантов.
добавляем сюда человекочитаемость (и «интутивность») sql и наличие худо-бедно соблюдаемого стандарта — среднестатистический разработчик напишет нужный селект на новом проекте независимо от используемой субд через 5 минут ковыряния в структуре бд, а не что-то на очередном «птичьем» языке (или вообще api) через несколько часов чтения документации.
я не спорю, nosql имеет свою нишу, но в 99% обычный sql банально удобнее/привычнее, а такого уж прямо highload'а нет
Let's Encrypt перевел серверы БД на AMD EPYC