PGBench для самых маленьких. Часть 1.

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

Самый простой способ, конечно - использовать встроенную утилиту pgbench. Но если ты сам не спец по СУБД и постгресу, то... тратить полгода на изучение, забросив все остальное?

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

А что делать, если тесты надо запускать много и в вариантах, да еще на пачке серверов, да еще разных архитектур?

Есть интересный пакет Phoronix Test Suite, и в рамках него есть встроенный pgbench тест, который буквально по одной команде сразу прогонит вам 80 вариантов (полторы недели на цикл).

$ phoronix-test-suite benchmark pts/pgbench

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

И вот мы делаем ррраз! И прогналось 80 тестов.

А есть там один нюанс - как и в большинстве бесплатных проектов, да в которые должны вкладываться десятки разных случайных людей, не обошлось без еще некоторых проблем.
А именно - в инсталляционном скрипте есть ошибка, из-за которой все тесты идут с буфером 8ГБ, хотя рекомендуемый буфер 1/4 от общего объема RAM.

Соответственно, необходимо зайти в (если тест ставился не от рута)
~/.phoronix-test-suite/installed-tests/pts/pgbench-1.14.0
или (от рута)
/var/lib/phoronix-test-suite/installed-tests/pts/pgbench-1.14.0

И исправить там скрипт запуска теста pgbench (имя файла). Выставляем размер в 1/4 от RAM (в мегабайтах).

SHARED_BUFFER_SIZE=131072

Вот теперь ваши результаты будут похожи на правду.

Продолжение следует.

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

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

Теоретики от ИБ решили посмотреть в глаза действительности. Но, как обычно, получилось не очень.

https://3dnews.ru/1112035/eksperti-utvergdayut-chto-slognie-paroli-snigayut-bezopasnost

«РТК-ЦОД» завершила ввод в эксплуатацию дата-центра «Москва-V»

В кластере дата-центров «Остаповский» запущены 4-я и 5-я очереди объемом 1024 стойки. Теперь ЦОД «Москва-V» полностью введен в эксплуатацию и вмещает 2048 стоек.

На сегодняшний день общая площадь ЦОД составляет 12 150 м², подведенная электрическая мощность — 17 МВт. Дата-центр соответствует уровню защищенности Tier III, то есть все основные жизненно важные инженерные системы объекта зарезервированы.

17 000 / 2048 / PUE = 8.3 кВт на стойку при идеальном PUE = 1
Чего конечно же быть не может. А при PUE = 1.5 получается 5,5 кВт на стойку.

Здравствуй, Даталайн 2024.

Это при массовом распространении AI систем с мощностью до 15 кВт на сервер. И при серверах с процессорами по 350 и 500 Вт.
Поставил два-три сервера в стойку и аля-улю, бери вторую стойку. Питание-то кончилось!

Нативные гипервизоры для VMware Workstation

"Workstation/Fusion давным давно использует нативные для ОС гипервизоры в качестве VMM"

В рамках обсуждения в одном из технических чатов новости про интеграцию KVM и VMware Workstation был высказан следующий тезис.

Мне лично показалось это крайне сомнительным, поскольку у меня на домашнем десктопе есть и VMware WorkStation 17 Pro, и Windows 11 Hyper-V, и на субъективный взгляд ВМ под разными гипервизорами ведут себя по-разному.
Ну а толку-то впустую спорить?

Сделал 2 идентичные ВМ - 4 vCPU, 24000 MB RAM, 200 GB disk. Одну в WS, другую в HV. Диски у обеих ВМ на одном и то же физическом диске, запуск тестов не пересекается. Для техно зануд - Ryzen9 7900X, 128 GB (4 * 32 DDR5-3600), Silicon Power XS70 4TB)
Туда Ubuntu 22.04.2, phoronix test suite.

Тест RO слабо нагружает CPU при единственном диске, но даже так отчетливо видно проседание WorkStation по производительности, под нагрузкой достигающее почти 3 раз (27304 / 73911 = 2,7х).
Если же тест более завязан на межпроцессное (и следовательно межпроцессорное) взаимодействе, и нагружает процессор, как RW тест (TPC-B like в терминах pgbench), то все становится еще более грустно.

Цитируя новость о WorkStation 15.5

"Introducing User Level Monitor

To fix this Hyper-V/Host VBS compatibility issue, VMware’s platform team re-architected VMware’s Hypervisor to use Microsoft’s WHP APIs. This means changing our VMM to run at user level instead of in privileged mode, as well modifying it to use the WHP APIs to manage the execution of a guest instead of using the underlying hardware directly.

What does this mean to you?

VMware Workstation/Player can now run when Hyper-V is enabled. You no longer have to choose between running VMware Workstation and Windows features like WSL, Device Guard and Credential Guard. When Hyper-V is enabled, ULM mode will automatically be used so you can run VMware Workstation normally. If you don’t use Hyper-V at all, VMware Workstation is smart enough to detect this and the VMM will be used."

Соответственно, это не означает, что WorkStation теперь работает прямо на Hyper-V, вместо использования собственного гипервизора. А просто начала использовать определенные системные вызовы, работая теперь полностью в User Level, а не конфликтуя с встроенными функциями виртуализации Windows.
Т.е. Workstation стала совместимой с Windows с установленными ролями Hyper-V и WSL. Но по производительности как была гипервизором 2-го типа, так и осталась.

Соответственно если вам нужна совместимость с ESXi, возможность подключиться к кластеру vSphere из одной консоли, или вам непринципиальна производительность - Workstation ваш выбор. В случае же потребности какой-никакой, но производительности от ВМ - только Hyper-V на десктопе.

Upd: по итогам обсуждения. Workstation действительно использует вызовы WHP (Windows Hypervisor Platform), чтобы обеспечить работу WS одновременно с Hyper-V.
Вот только Hyper-V != WHP. WHP работает как вложенный гипервизор поверх Hyper-V.
Оттуда и разница.

Какая связь между World of Tanks и переменными окружения?

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

Вот есть игрушка "Танки", которую пишут разработчики, а помогают им девопсы и все модные и красивые, клауд-нейтив ололо.
Но весь клауд-нейтив ломается на древней как мир вещи - на переменных окружения, хотя казалось бы где Танки и досовские (консольные) переменные?

Оказывается, что в новой модной игрушке где-то глубоко зашита древняя (в смысле заслуженная) утилита curl, которая видит ваши переменные окружения, и в частности http_proxy, и если таковая есть - лезет в интернет через этот прокси. Вне зависимости от того, есть в настройках самой игры подключение через прокси или прямое. В итоге если у вас на десктопе по какой то причине есть специфическая конфигурация сети, чтобы разный софт в интернет ходил по-разному, то нет, не получится поиграть. Танки не запустятся, если этот curl не сможет проломиться через этот http_proxy.
Разработчики Танков решили не заморачиваться нативными способами доставки контента в единой сетевой модели - они просто обернули curl.
Потому что ну вы знаете - так в примерах показано, чего там уж париться?

И это простой пример. А сколько у вас таких примеров и копи-пасты кода пораспихано по проду? Знаете ли вы все зависимости и требования своего софта?
Сколько кода у вас вообще подсасывается из гитхаба при сборке, а не хранится в локальных репозиториях?

Что мешает корпоратам продавать внутренний софт на внешнем рынке?

Многие компании, включая Сбер, активно разрабатывают собственное программное обеспечение.
Однако возникает вопрос: что мешает продавать это программное обеспечение на внешнем рынке?

Возник в обсуждении следующий вопрос.

Итак, что же мешает?

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

Получается затратно и не выгодно для организации организовать продажу своего ПО.

Да, затратно.

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

Если взять бизнес-софт, разработанный условным Сбером - кому его продавать? Много ли вообще покупателей найдется на такой софт, с учетом разницы калибров?

А если взять такой же софт, разработанный банком из "топ 397", то что с ним должен делать условный Сбер со своими оборотами и количеством транзакций в день?
Уверены ли вы, что банк из "топ 397" архитектурно заложил уровни нагрузки, защиты, обеспечил соответствующее тестирование, чтобы Сбер взял и купил его вместо написания своего?

Но софт может быть не заточен по инфраструктуру, по направлениям к примеру: редактировать текст, работа с видео, работа со звуком, распознавание текста со скана и т.д.- то что можно установить на ноутбук или на рабочую станцию.

Т.е. вы считаете, что банкам и прочим крупным ИТ конторам нечем заняться, поэтому внутренняя ИТ разработка занимается очередным текстовым редактором (1002м на рынке), пишет обработку видео (монтаж и прочеее), и вообще занимается универсальным пользовательским софтом, вместо того, чтобы взять с рынка или из опенсорса готовую софтину?

Предположим какие то пересечения есть. Можно даже что то найти.

Итого:
1. Организовывается спец отдел для аудита всего кода и всей разработки - что вообще в принципе можно отдать
2. Организовывается особый отдел по очистке внутренней разработки, которая никогда не планировалась на открытый рынок
3. Еще один комитет по принятию решений
4. Потом еще один комитет по интеллектуальной собственности
5. комитет по принятию решений по безопасности - можно ли вообще это отдавать

Это ФОТ, время, найм, работа.

После Х затрат решения приняты.

Код готов к выдаче командам, которые займутся разработкой на открытый рынок (а где они, мы же их не наняли).

Или организуется НИИ "СпецКодХран", в который все *Банки, *Ойлы и остальные начинают сгружать этот код?
А кто его дальше двигает в универсальную среду, чтобы он начал развиваться?

А что делает *Ойл, сгрузивший очищенный код? Замораживает кодовую базу и ждет пока НИИ СКХ выпустит релиз? А что если НИИ СКХ делает это слишком медленно или развивает продукт не в ту сторону? Должен ли *Ойл менять свои бизнес процессы под роадмап НИИ СКХ?

Конечно нужен аудит, что есть на рынке, и что ждёт государство от ит в качестве #ракетаИмпортозамещения

А кто аудит делает-то? НИИ СпецКодПоиск? Тогда как они получают доступ к закрытой информации и ком тайне?
Собственными силами?

Итого, что мешает продавать внутренний ИТ продукт на рынке?

Ответ: это непрофильный бизнес для абсолютного большинства. Перевод продуктов из внутренних во внешние - это организация нового непрофильного ДЗО с туманными перспективами в ситуации острой нехватки кадров.

Как защититься от шифровальщиков?

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

Это очень важно, ни в коем случае не отрицаю. НО!
Значительно важнее, а самое главное проще, дешевле и надежнее СНАЧАЛА реализовать вариант устойчивости к шифровальщику, который уже пробрался и нашифровал.

1. Схема резервного копирования с регулярным дублированием копий на отчуждаемые носители, лежащие в сейфе.

Нельзя зашифровать только те данные, которые не подключены в сеть. Исходя из этого ваш RPO равен промежутку между выкладыванием лент в сейф. Если ленты остались в библиотеке - они могут быть зашифрованы или испорчены.

2. Особо ценные данные размещать на СХД корп класса с поддержкой дискового журналирования класса EMC RecoverPoint (да-да, я знаю что он мертв), или снапшоты раз в 15-30 минут для снижения RPO


Конечно, лучше бы не допускать шифровальщиков, но делать упор на перевентивные меры, отрицая СРК?
Если вы пропустите угрозу, то при бэкапах вы можете восстановить. А без них закрывайте компанию
Это как отрицать антибиотики потому что пьешь витамины и руки моешь

"Тогда надо включать пункт про криптокошелек - держу 10K$ и больше в битке для оплаты на ключи шифрования )))) таких кто платил видел лично"

It depends. Если у вас политически (по решению СБ и руководства) разрешены переговоры с террористами (авторы и распространители шифровальщиков = террористы) и вы готовы их прикормить, то да, для вас это просто расходы.
Правда есть нюанс, что не расшифруют.

"Надо следовать правилу 3-2-1"

3-2-1 как любой бестпрактис - лучше, чем ничего вообще.
Но не надо в него упираться. Иногда есть варианты лучше и правильнее для конкретного кейса.

Любой бестпрактис надо осознать, положить в контекст, в том числе исторический. И понять попадает ли ваш кейс по угрозам в модель угроз, для которой написан этот бестпрактис.

И даже в этом случае сделать возможность бэкапа на отчуждаемые носители мало. Необходимо внедрить это в процесс и вовлечь СБ в контроль, потому как иначе на все будет забито.
При этом обязательно нужен план восстановления, детальным и пошаговый, чтоб когда придет время, админы смогли его взять и выполнить.
Причем пошаговым прямо в расчете на то, что его придется выполнять в 4 утра первого января пьяному и очень нервному инженеру

В обязательно же порядке добавляем тестирование РК и внешних (отчуждаемых) носителей.
И тестируем не только носитель, а весь процесс восстановления.

Есть прохладная история из асашайки.

Была контора, где внедрен был процесс РК на лентах, которые отвозили в архив на аутсорсе (Iron Mountain). И вдруг бац, надо восстановиться.

Съездили за лентами, восстанавливаются из лент- ан хрен, полная копия (понедельник) запорота. Отправили за недельными лентами.
Та же история.
В итоге потеряли данные за 4 месяца.

Начали выяснять. Оказалось, что вообще то ленты в архив возит один и тот же мужик. Но 4 месяца назад у него то ли жена родила, то ли что то семейное случилось и теперь он по понедельникам должен отвозить детей в школу и договорился, что в понедельник ленты отвозит другой дядька.

Дядька нормальный, ни в чем не замечен, злого умысла никто не нашел. Пошли уже прям досконально - давай показывай как ты едешь, везешь.

Показывает. Подходит к машине, кидает ленту в багажник.
А там у него ИПИЧЕСКОГО размера сабвуфер!

Неделю назад легла зона в Я.Облаке. Специально подождал пока утихнут страсти и мнения, и будет понятно что случилось.

Кратко. Легло питание.

У всех корпоративных инфраструктурщиков сразу вопрос - а что, ДГУ не запустились?

- Пэйн, я ДГУ не вижу!
- А их и нет!

ДГУ в проекте даже не были предусмотрены. И нет, это не ошибка, это вполне взвешенное решение от проектировщиков Я.Облака.

Много лет я вижу что на конференциях, что у заказчиков, тему от облачных провайдеров "да зачем вам свое ИТ, приходите к нам, у нас железо, ЦОДы и спецы."
И следом ррраз - коммерческое предложение с очень привлекательной ценой в месяц против каких то чудовищных сотен миллионов или даже миллиардов рублей за собственный онпрем ЦОД.

И вот здесь и кроется интересный момент в сравнении.

Онпрем можно построить с любой заданной степенью надежности, математически доказанной. Нужна устойчивость от катастроф - построим метрокластер, репликацию, что угодно. Да, это стоит денег, это часто очень дорого. Но при этом с минимальными, а то и вообще без изменений ландшафта ПО. Это инфраструктурный проект, почти не затрагивающий прикладной слой.
Мы поставим ИБП, ДГУ, лазерную связь, спутниковую - все это может быть реализовано в онпрем, если ведет к снижению простоев и потерь данных. Но дорого и очень много капитальных затрат + сроки реализации.

Облако очень удобно, минимальные стартовые затраты, оплата по факту, ничего строить не надо, доступно сразу.
Облако надежнее и лучше пока нет своей инфраструктуры и инфраструктурщиков, а есть только пара-тройка гениальных программистов в стартапе.

Но по мере роста сложности и объемов бизнеса начинают вставать вопросы надежности. И здесь мы упираемся в термины "оферта" и "SLA", а конкретно уровня штрафных санкций за нарушение SLA.
Если в онпреме мы строим инфраструктуру, не ограничивая уровень ответственности, а считая прямые убытки от простоев / потери данных, то облаку все это не требуется. Все это ограничено 15-30%, ну пусть даже 100% (что почти нереально) одного месячного платежа. И соответственно нет никакого резона строить инфраструктуру облака, которая будет дороже, чем возможные штрафные санкции в виде скидки размером в месячный платеж.
И вот тут мы и приходим к вопросу почему у Я.Облака ДГУ просто нет в проекте. А есть вероятности выхода из строя питающих подстанций и стоимость простоя при маловероятном выходе из строя сразу двух. Матожидание, если в терминах теории вероятности. Стоимость ДГУ попросту кратно превышает ответственность, поэтому ДГУ там не нужны.

Как же тогда обеспечивать надежность? О, ну тут просто - вы просто берете и переписываете весь прикладной слой, чтобы он работал в двух, трех зонах доступности в асинхронном режиме. Ведь между зонами сеть не позволяет делать метрокластеры и работать синхронно, слишком разнесены зоны географически.
А в момент переписывания вы разумеется берете значимое количество "managed" сервисов облака. Зачем брать только ресурсы и строить все балансировщики, БД, хранение? Берем их в готовом виде и строимся уже не в IaaS, а в PaaS. В нескольких зонах. И живем, все у нас прекрасно.

Пока не захотим съехать в другое облако или даже в онпрем. Почему мы же мы можем захотеть съехать в онпрем?
1. Мы слишком выросли, своя инфраструктура становится в разы дешевле облака.
- Пример Dropbox. 100% выросший в AWS был вынужден не то что инфраструктуру свою строить, а начать покупать магистральных провайдеров. Слишком вырос трафик и популярность.
2. Требования регулятора, опасность полит. плана.
- Пример AWS vs Parler.
3. и еще много вариантов

Ключевой момент. Облако - это не про технологическое лидерство, это про как максимально сэкономить и снизить стоимость MHz, GB RAM, TB хранения, чтобы перепродать дороже. Вплоть до отказов от ДГУ и вообще резервирования, если это поможет продаваться.
И если у вас нет своих инфраструктурщиков, которые будут понимать как и где может развалиться ваша виртуальная облачная инфраструктура, и знающих как построена физика внизу, чтобы вовремя вас предостеречь - может быть мучительно больно.

Один заказчик устроил серверную в самом защищенном помещении - бывшей оружейной комнате. Стены 1м толщиной, мощная дверь. Кондиционера нет - слишком трудно и дорого. В результате - дверь в серверную была всегда открыта, рядом колхоз направленного охлаждения.

+1 история в "Ошибки капитального строительства как фактор ИБ"

Это не может быть DNS!

Если у вас происходит необъяснимая фигня в сети, не поддающаяся логике. Если соединения то проходят, то не проходят. Если соединения идут, но не все.
Есть ровно один главный кандидат - DNS. И два его подручных - BGP и DHCP.

Давайте поговорим о диагностике участия DNS. Я в очередной раз потратил три дня на раскопки и разборки с системным ПО из-за DNS, поэтому будет и мне напоминанием. Все приведенные кейсы реальны.

1. Кейс об отсутствующих DC/DNS

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

Причина - исторически сложилось, что в терминальном брокере были прописаны DNS3, DNS2 (совмещенная роль AD/DNS), но по ходу эксплуатации DNS3 остался резервным и перешли на DNS1, DNS2. И при очередных работах DNS3 просто забыли включить назад. Сменили на брокере DNS на актуальные - логин стал моментальным.

2. Кейс о нестабильном сетевом коннекте.

Сервер приложений то отвечает, то не отвечает. Любые корреляции случайны, включая фазы луны. Обращение в ТП сервера приложений стало просто анекдотичным.

- Пришлите нам tcpdump
- Вот, смотрите - запрос есть, ответа нет
- А вот смотрите у нас в лабе есть запрос и есть ответ.

- Алло, пожарные, у меня 9-этажка напротив горит!
- Да? А у меня напротив такая ж 9-этажка и не горит.

Технологический ландшафт. В конторе две технических службы, одна из которых классические офисные ИТ, а вторая тоже ИТ, но не офисная от слова совсем. Сервер приложений в ведении ИТ2, и у ИТ2 даже свой собственный сетевой сегмент, свои серверы и даже маленький технологический домен с собственными DNS.
На серверах DNS ИТ2 стоит безусловный форвард на DNS ИТ1 всех неизвестных запросов.

Причина. Сервер приложений по какой-то неизвестной причине обязательно делал реверс-DNS запрос по каждому клиенту. Поскольку обращение к серверу приложений в технологической зоне шло с офисной машины администратора, то реверс-запрос сразу форвардился на DNS ИТ1, а там на одном из трех DNS были в наличии не все реверс-зоны.

Потеряно 3 недели и целая куча нервов во взаимных обвинениях между ИТ1, ИТ2 и разработчиком сервера приложений.

3. Кейс о машинах VDI, которые то добавляются, то не добавляются

Администратор создает VDI машины и добавляет их в пул. Но иногда случается ситуация, что машина добавляется на пол-шишечки. Т.е. все всех видят, стабильная сетевая связность, но агент не может соединиться с брокером. При этом сетевая связность машины (на которой агент) с сервером (на котором брокер) есть и безупречная - 25 Gbit один хоп.

Причина. Машины VDI находятся в зоне технологической лаборатории и бывает так, что в DNS остались записи на тот же IP, а часть записей никто не вносил. Судя по всему, снюхивание агента с брокером зависит от DNS и в частности реверс-DNS, поэтому очистка DNS от лишнего и прописывание прямых и обратных адресов сработала.

Итоговая методичка по проверке DNS
1. Нарисуй структуру всех участвующих DNS и кто кому форвардит
2. Разбей DNS на группы, и напиши какие группы отвечают за какие зоны
3. Проверь, что репликация зон настроена на всех DNS из каждой группы
4. Проверь, что на всех DNS есть все зоны, включая обратные зоны
5. Проверь, что нет лишних записей с теми же адресами
6. Проверь, что все адреса внесены в DNS, включая обратные зоны

На злобу непогоды дня.
+1 история "Ошибки капитального строительства"

"Жила была одна компания, которой досталось здание то ли от ночного клуба, то ли от сауны, то ли от того и другого вместе. Компания не занималась ничем вышеупомянутым, так что пришлось приспосабливать помещения под обычную офисную деятельность.
И был там бассейн, в котором уже давно никто не плескался. Долго ли, коротко ли, но решили этот бассейн использовать под серверную, а прямо в чашу бассейна стойки и поставили.

Водопровод, разумеется, перекрыли. Да вот случилась непогода сильная, лютая. Затопило все ливнёвки и канализацию. И оказалось, что водопровод то в бассейне перекрыли, а вот слив в канализацию нет.
И организовалось стихийное жидкостное охлаждение иммерсионное прямо для всего серверного хозяйства. С понятным результатом."

На фоне очередных успехов очередного ЦОДа с питанием
+1 история "Ошибки капитального строительства"

Компания организовала 2 ввода, 2 (!) ДГУ, АВР (автоматический ввод резерва). Все по красоте!

Случается инцидент по питанию - всё ложится, питания нет.

А разгадка одна:

2 ввода, АВР - они только на входе. Раз у нас все хорошо и резервировано, то после АВРа в машзал идет один луч питания с одним автоматом.
Этот автомат и сгорел.