Тут стараемся не полностью от OOM Killera избавится, а снизить вероятность, что он "убъёт" наш процесс PostgreSQL. Чудес действительно не бывает: реалии таковы, что на одной машинке с постгресом ради экономии может крутиться много постороннего ПО - какой-нибудь pgadmin4, да и у 1C:предприятия есть своя версия для linux. По SSD: Во-первых: 2TB SSD в 3х экзеплярах для самого простого кластера patroni с потоковой репликацией - иногда выходит дороговато. HDD, увы, пока ещё производятся и дёшевы. Во-вторых: это касается только крайне высоконагруженных систем или крайне неоптимизированных запросов. Но всё же, упереться в конкуренцию на запись или пропускные возможности контроллера - возможно.
Естественно, если база на пару гигабайт, к ней подключаются 5 с половиной пользователей и всё это при хорошем железе, то никакой тюниг особо не нужен.
Если на сервере несколько кластеров (в терминологии постгреса так называется инстанс), то конкуренция за ресурсы между ними будет в любом случае. Её можно только попытаться минимизировать, зная предполагаемую нагрузку на каждый кластер.
Добрый день! Систему регулярно проверяет специальная команда с лицензией МЧС. Но, помимо этого, мы как минимум раз в квартал проверяем все сами: вызываем срабатывание разных датчиков, пожарная сигнализация срабатывает и наш персонал выполняет действия по тушению предполагаемого возгорания. Во время тренировки происходит полная эвакуация персонала и посетителей из здания ЦОД.
Добрый день! Стандартная температура холодного коридора - 25 градусов, плюс-минус 2 градуса. В горячем коридоре бывает по-разному, зависит от множества факторов.
Добрый день! Мы рассказываем о дата-центрах компании "Ростелеком-ЦОД". В ее сеть входят площадки в Москве, Санкт-Петербурге, Удомле, Екатеринбурге и Новосибирске. А ЦОД на Сахалине принадлежит ПАО "Ростелеком", и он действительно самый восточный в России :)
Спасибо, уточнили формулировки. Первый пункт дополнили ― действительно, сначала мы тестировали по описанным шагам виртуальное решение на нашем оборудовании виртуализации. Это помогло обкатать сценарий тестирования. А потом уже решились на эксперименты с другим оборудованием.
Про массовое внедрение такой схемы речи здесь нет, скорее, это временное решение на случай задержек с закупками новых ПАКов и т.п. Мы показали вариант для единичных специфических запросов, которые нам встречались, и поделились способом проверки UserGate на прочность.
Имеется в виду, что если использовать ролевую модель, помимо безопасности появляется очень простой механизм для приоритизации запросов.
Речь идет о штатном переключении, например для обновлений OS (нештатные — это уже другая история). Перед таким штатным переключением в скрипте появляется возможность текущую нагрузку распределить: "запросы от этих пользователей commit, а вот от этой группы можно и rollback".
Также перед переключением обязательно нужно смотреть нагрузку, иначе можно попасть на долгое переключение, например, когда наполовину выполненный merge долго откатывается обратно.
Всё так ― здесь мы хотели дать принципиальные рекомендации без привязки к одному инструменту и рассматривали ситуации, когда сервер арендуют для проверки гипотез и даже возможно воспринимают его как "временный". А про Terraform напишем отдельно :)
390 метров ― это по-видимому скорее экспериментальная величина, чтобы проверить работу системы не только на близком расстоянии, но и на дальнем. И определить границы применения в зависимости от дистанции.
На 60 метрах они так и сделали, как вы описали: ставили столы с оборудованием с двух концов здания и вставляли устройства. Но в выводах о практическом применении они упоминают, что это расстояние можно сократить до нескольких футов. И схему предлагают скорее такую: пользователь подходит к банкомату, у которого слоты для токена расположены с двух противоположных концов, чтобы их можно было вставить на расстоянии вытянутых рук.
По поводу устойчивости схемы против запутанных токенов в открытых публикациях этих ученых мы пока нашли только один абзац. Так что подождем продолжения исследований, видимо)
Данная схема ― это не конкретный клиент, а скорее наши возможности по его подключению к нам с использованием серых автономных систем и анонсом нам же арендованных у нас адресов. Внутри между маршрутизаторами клиента может быть что угодно, на его усмотрение: хоть iBGP, хоть eBGP, хоть любой из igp протоколов, главное ― это организация внутренней связности.
В конкретно данном примере показан вариант с двумя роутерами без организации RR, но это в любом случае не схема конкретного клиента, а общая модель.
Опять же, если мы говорим о том, что в сегменте клиента появляется RR, он явно должен быть не один для обеспечения отказоустойчивости.
Обновили ссылку сразу на PDF с исследованием.
С мнемоникой для паролей есть 2 пути:
— сгенерировать рандомную информацию и придумать правило для ее запоминания. Да, есть небольшой риск, что сама фраза забудется или вдруг заклинит, как же ее «свернуть» обратно в пароль. Скорее, всего, с одним таким паролем этот риск минимален. Но если таких паролей 10+, то далеко не каждый пользователь захочет сильно заморачиваться.
— взять мнемоническую фразу и «свернуть» ее в пароль по определенным правилам — в исследовании выше речь как раз об этом. С одной стороны, можно было бы брать сколь угодно личную фразу, которую никто не знает. Но чаще люди берут строчки из песен, цитаты известных людей и пр. Такие мнемоники уже можно взломать.
Тут стараемся не полностью от OOM Killera избавится, а снизить вероятность, что он "убъёт" наш процесс PostgreSQL.
Чудес действительно не бывает: реалии таковы, что на одной машинке с постгресом ради экономии может крутиться много постороннего ПО - какой-нибудь pgadmin4, да и у 1C:предприятия есть своя версия для linux.
По SSD:
Во-первых: 2TB SSD в 3х экзеплярах для самого простого кластера patroni с потоковой репликацией - иногда выходит дороговато. HDD, увы, пока ещё производятся и дёшевы.
Во-вторых: это касается только крайне высоконагруженных систем или крайне неоптимизированных запросов. Но всё же, упереться в конкуренцию на запись или пропускные возможности контроллера - возможно.
Естественно, если база на пару гигабайт, к ней подключаются 5 с половиной пользователей и всё это при хорошем железе, то никакой тюниг особо не нужен.
В состояние гонки дисковую подсистему воркеры не введут, если инстансы на разные диски положить.
Если по ВМ не разделять, то базу можно сделать одну, а внутри разделение по схеме делать. Но это уже сложности со стороны 1с
Если на сервере несколько кластеров (в терминологии постгреса так называется инстанс), то конкуренция за ресурсы между ними будет в любом случае. Её можно только попытаться минимизировать, зная предполагаемую нагрузку на каждый кластер.
Да, лучше использовать такой подход
Добрый день! Систему регулярно проверяет специальная команда с лицензией МЧС. Но, помимо этого, мы как минимум раз в квартал проверяем все сами: вызываем срабатывание разных датчиков, пожарная сигнализация срабатывает и наш персонал выполняет действия по тушению предполагаемого возгорания. Во время тренировки происходит полная эвакуация персонала и посетителей из здания ЦОД.
Наши системы пожаротушения регулярно проверяются, все работает :).
Добрый день! Стандартная температура холодного коридора - 25 градусов, плюс-минус 2 градуса. В горячем коридоре бывает по-разному, зависит от множества факторов.
Добрый день! Мы рассказываем о дата-центрах компании "Ростелеком-ЦОД". В ее сеть входят площадки в Москве, Санкт-Петербурге, Удомле, Екатеринбурге и Новосибирске. А ЦОД на Сахалине принадлежит ПАО "Ростелеком", и он действительно самый восточный в России :)
Нет :), мы построили новое здание ЦОД рядом с уже существующим зданием АТС Ростелекома, в котором располагается старый ЦОД.
Спасибо! И хорошего дня :)
Спасибо, уточнили формулировки.
Первый пункт дополнили ― действительно, сначала мы тестировали по описанным шагам виртуальное решение на нашем оборудовании виртуализации. Это помогло обкатать сценарий тестирования. А потом уже решились на эксперименты с другим оборудованием.
Про массовое внедрение такой схемы речи здесь нет, скорее, это временное решение на случай задержек с закупками новых ПАКов и т.п. Мы показали вариант для единичных специфических запросов, которые нам встречались, и поделились способом проверки UserGate на прочность.
Имеется в виду, что если использовать ролевую модель, помимо безопасности появляется очень простой механизм для приоритизации запросов.
Речь идет о штатном переключении, например для обновлений OS (нештатные — это уже другая история). Перед таким штатным переключением в скрипте появляется возможность текущую нагрузку распределить: "запросы от этих пользователей commit, а вот от этой группы можно и rollback".
Также перед переключением обязательно нужно смотреть нагрузку, иначе можно попасть на долгое переключение, например, когда наполовину выполненный merge долго откатывается обратно.
Всё так ― здесь мы хотели дать принципиальные рекомендации без привязки к одному инструменту и рассматривали ситуации, когда сервер арендуют для проверки гипотез и даже возможно воспринимают его как "временный".
А про Terraform напишем отдельно :)
390 метров ― это по-видимому скорее экспериментальная величина, чтобы проверить работу системы не только на близком расстоянии, но и на дальнем. И определить границы применения в зависимости от дистанции.
На 60 метрах они так и сделали, как вы описали: ставили столы с оборудованием с двух концов здания и вставляли устройства. Но в выводах о практическом применении они упоминают, что это расстояние можно сократить до нескольких футов. И схему предлагают скорее такую: пользователь подходит к банкомату, у которого слоты для токена расположены с двух противоположных концов, чтобы их можно было вставить на расстоянии вытянутых рук.
Спасибо, важные уточнения, скорректировали!
По поводу устойчивости схемы против запутанных токенов в открытых публикациях этих ученых мы пока нашли только один абзац. Так что подождем продолжения исследований, видимо)
Данная схема ― это не конкретный клиент, а скорее наши возможности по его подключению к нам с использованием серых автономных систем и анонсом нам же арендованных у нас адресов. Внутри между маршрутизаторами клиента может быть что угодно, на его усмотрение: хоть iBGP, хоть eBGP, хоть любой из igp протоколов, главное ― это организация внутренней связности.
В конкретно данном примере показан вариант с двумя роутерами без организации RR, но это в любом случае не схема конкретного клиента, а общая модель.
Опять же, если мы говорим о том, что в сегменте клиента появляется RR, он явно должен быть не один для обеспечения отказоустойчивости.
Количество варьируется от 2 до 9, в зависимости от задач и размеров площадки.
Пока не доводилось. Но спасибо за наводку!
С мнемоникой для паролей есть 2 пути:
— сгенерировать рандомную информацию и придумать правило для ее запоминания. Да, есть небольшой риск, что сама фраза забудется или вдруг заклинит, как же ее «свернуть» обратно в пароль. Скорее, всего, с одним таким паролем этот риск минимален. Но если таких паролей 10+, то далеко не каждый пользователь захочет сильно заморачиваться.
— взять мнемоническую фразу и «свернуть» ее в пароль по определенным правилам — в исследовании выше речь как раз об этом. С одной стороны, можно было бы брать сколь угодно личную фразу, которую никто не знает. Но чаще люди берут строчки из песен, цитаты известных людей и пр. Такие мнемоники уже можно взломать.