С другой стороны, если какая-то оптимизация привела к реальному повышению прибыли, то почему нельзя честно поделиться 10% от полученного эффекта с тем, кто его придумал? Ведь 90% всё равно останутся предприятию. И все в плюсе — человек мотивирован, предприятие развивается. Ведь если приглашают консалтинг, то как-то мирятся с необходимостью им платить? Или когда сейлз переплюнул план продаж? Просто у нас отношение к рядовым сотрудникам часто такое, что грубо говоря за еду он должен круглосуточно тратить все свои физические и умственные усилия во благо хозяина. Рабовладельческое, а не партнерское.
У 3ware была неплохая утилита tw_cli, потом когда они попали под крыло LSI — появилась storcli, с тем же синтаксисом. Вот ими еще можно пользоваться, сделаны по-человечески. В отличие от старых lsiutil, megacli и hpacucli.
Расскажу про то, как у меня решена похожая задача. Картинки, в день исходящий трафик больше 14 ТБ, пиковая скорость — до 8 Гбит/с.
На AWS Route 53 создан alias для домена, указывающий на 16 адресов кэширующих серверов. По днс запросу домена отдаются multiple A-records, 8 адресов, ttl 60s, порядок меняется с каждым запросом. Для каждого адреса кэширующего сервера в Route 53 настроен health check порта 443/tcp (можно и http на liveness url, но будет чуть дороже). В случае недоступности порта на каком-то адресе, health check реагирует на это за 30-60 сек и выкидывает адрес из днс выдачи у домена. Еще до 60 сек (помним про ttl алиаса) нужно чтобы старая днс запись у клиента протухла и он сходил за новой. Таким образом время недоступности домена у 1/16 клиентов наткнувшихся на упавший адрес составит от 30 до 120 сек максимум. И то, только если ПО клиента не умеет доставать следующие адреса из днс ответа самостоятельно (браузеры например умеют, мобильные приложения насколько я знаю — тоже). Дальше, на этих 16 кэширующих серверах (8 на ДЦ) настроена в nginx балансировка по 2 стораджам из своего ДЦ + 2 стораджа из второго ДЦ указаны с опцией backup. Если ответ с ошибкой или кончился таймаут (специально поставлен небольшим) — отправляем запрос на другой сторадж. Стораджи отдают в день до 4 ТБ за счет кэширующего слоя, а клиентам уходят 14 ТБ.
В такой схеме спокойно живется как при отказе любого сервера, так и при недоступности одного ДЦ. Небольшая часть клиентов при сбоях увидит или небольшое повышение времени ответа, либо недоступность не более 1-2 мин. Ручные действия не требуются, в PagerDuty присвоен низкий приоритет на алерты. Используемое ПО — только бесплатный nginx, за Route 53 — несколько десятков $ в месяц.
Не использую блокировщики, потому что нет доверия создателям расширений браузера — на чем их только уже не ловили, или сами начинают еще больше данных собирать и сливать, или их репозиторий ломали и заразу подкладывали.
А вообще когда сидишь за VPN другой страны, язык которой не знаешь — реклама идет тоже не рускоязычная, и она не так отвлекает и бросается в глаза, мозг видимо сам фильтрует незнакомые сочетания символов.
Против демонстрации на примере k8s ничего не имею, всё-таки это сейчас самый популярный инструмент, а само описание пунктов 13-16 легко натянется и на другой и останется верным.
А вот пункты 17-19 это уже что-то из разряда IBM Cloud only, к ним как раз больше всего вопросов. Но надо понимать что раз статья из блога IBM Cloud — значит и писать они будут про себя.
Верно, тоже ей пользовался, но неоднократно видел мнение что upsdiag правильно работает только со старыми моделями, а при использовании на новых может напортачить записав не то и не туда.
При подключении по rs232 (на самом деле не совсем, нужен специальный кабель apc) — из терминала есть команды для этого, либо есть софтина apcfix для win, которая отправку этих команд в gui обернула (http://apc-fix.com/apcfix).
На APC по поводу battery runtime — достаточно корректно работает на новом ибп после покупки, отслеживает время работы без батарей от полного заряда до низкого уровня напряжения, при определенном уровне нагрузки, и соответственно пишет прогнозируемое время работы от батарей в регистры (которые в обычном режиме работы могут только уменьшаться).
Проблемы начинаются после самостоятельной замены батарей (хоть кто-то здесь возил ибп в СЦ schneider-electric за этим? не думаю). Так вот после простой замены — значения регистров сами не сбрасываются, а остаются такими, какие были на старых батареях перед смертью. Именно в этот момент показатель прогнозируемого времени работы от батарей и начинает показывать погоду на Марсе. Чтобы восстановить нормальное функционирование необходимо делать сброс регистров и последующую калибровку — регистры перезаписываются на максимальное значение, батареи заряжаются до 100% и не менее 12 часов, затем подключается нагрузка не менее 40% от номинала ибп, и начинается работа на батареях, разряд до низкого уровня напряжения. По завершении алгоритм ибп сможет примерно рассчитать прогнозируемое время работы, запишет регистры, а показания станут более достоверными. Такую процедуру придется проводить при каждой замене.
Если речь идет про отчуждаемый сервис от остальной инфраструктуры заказчика — заказчик выделяет разработчику отдельный пул ресурсов (например группа виртуалок у облачного провайдера), развертыванием и сопровождением полностью может заниматься разработчик.
Если сервис интегрируемый и неотчуждаем от инфраструктуры заказчика — то развертывание осуществляется заказчиком, а разработчик просто не реализует этап Continuous Deployment, т.е. делает всё вплоть до поставки готового артефакта заказчику.
Странным выглядит предложение конвертить yaml в json для чтения, а не наоборот. Ведь миссия yaml как раз в повышении человеко-читаемости. И на мой взгляд он хорошо справляется с этим, попробуйте прочитать или написать с нуля без IDE — xml, json и yaml.
Может под OLAP данные не менялись, и в тот же кликхаус данные писались также как в mysql — в одной строке одна метрика.
По идее в этом случае нужно писать в одну строку — все метрики из одного источника за один timestamp, по колонкам. eapotapov, как было?
Аналогичную картину можно наблюдать на балансировщике, когда бэкенд завален работой и время обработки запросов уходит до таймаутов — на балансировщике наблюдается стремитпльный рост количества открытых соединений и запросов в секунду, хотя клиентов больше не стало — просто запросы приходят и копятся, т.к. ждут ответа.
Я потому и упомянул, что для доверия в подобной системе нужно сразу иметь открытость by design, распределенную обработку и хранение, и доверие на основе математики, криптографических подписей и блокчейна, а не на слепом авторитете.
В текущей ситуации доверять власти что она хочет и может провести выборы честно — всё равно что садиться играть с шулером, надеясь на то что он джентльмен.
Особенно учитывая, что задействованные люди — находятся в крайне зависимой и управляемой позиции от власти.
Система электронного правительства и голосования по типу Эстонии (для большего вовлечения людей в процесс выборов, а также для избежария ручного труда подчиненных людей) + opensource софт приложения и системы голосования + работа системы прдсчетов по принципам децентрализованности и распределенных систем + криптография на каждом этапе + распределенный блокчейн в качестве хранилища результатов. И затем привлечение мировой экспертизы для проверки работы такой модели и ее математического доказательства. И тогда может быть мы сможем доверять получаем результатам, и сможем проверить и посмотреть цифры прямо у себя на устройстве, а не с сайта под чужим недоверенным управлением.
Интересно насколько Virtuozzo 7 может решить описанные здесь проблемы? Ведь под капотом там те же технологии, а в преимуществах должен быть как раз удобный способ работы с виртуальными машинами и контейнерами в едином интерфейсе. Есть у кого-нибудь опыт эксплуатации?
Я застал OS/2 на банкоматах, только не на тех что в поле (эти были все на Windows XP, и только самые новые — на Windows 7), а на использовавшемся в качестве диагностического стенда для различных модулей. Т.к. для тех моделей банкоматов родной системой была именно OS/2, и возможности имевшегося в ней софта для диагностики были более детальными, чем в версии под Windows XP.
При этом для сборки этого стенда под диагностику, приходилось использовать образ диска, крайне предусмотрительно снятый с одного из последних живых и не обновленных банкоматов с этой системой. И заводилось всё это дело только на системниках с Pentium 3, на IDE дисках размером не более 20Гб (еще и не любого производителя).
С другой стороны, если какая-то оптимизация привела к реальному повышению прибыли, то почему нельзя честно поделиться 10% от полученного эффекта с тем, кто его придумал? Ведь 90% всё равно останутся предприятию. И все в плюсе — человек мотивирован, предприятие развивается. Ведь если приглашают консалтинг, то как-то мирятся с необходимостью им платить? Или когда сейлз переплюнул план продаж? Просто у нас отношение к рядовым сотрудникам часто такое, что грубо говоря за еду он должен круглосуточно тратить все свои физические и умственные усилия во благо хозяина. Рабовладельческое, а не партнерское.
У 3ware была неплохая утилита tw_cli, потом когда они попали под крыло LSI — появилась storcli, с тем же синтаксисом. Вот ими еще можно пользоваться, сделаны по-человечески. В отличие от старых lsiutil, megacli и hpacucli.
Расскажу про то, как у меня решена похожая задача. Картинки, в день исходящий трафик больше 14 ТБ, пиковая скорость — до 8 Гбит/с.
На AWS Route 53 создан alias для домена, указывающий на 16 адресов кэширующих серверов. По днс запросу домена отдаются multiple A-records, 8 адресов, ttl 60s, порядок меняется с каждым запросом. Для каждого адреса кэширующего сервера в Route 53 настроен health check порта 443/tcp (можно и http на liveness url, но будет чуть дороже). В случае недоступности порта на каком-то адресе, health check реагирует на это за 30-60 сек и выкидывает адрес из днс выдачи у домена. Еще до 60 сек (помним про ttl алиаса) нужно чтобы старая днс запись у клиента протухла и он сходил за новой. Таким образом время недоступности домена у 1/16 клиентов наткнувшихся на упавший адрес составит от 30 до 120 сек максимум. И то, только если ПО клиента не умеет доставать следующие адреса из днс ответа самостоятельно (браузеры например умеют, мобильные приложения насколько я знаю — тоже). Дальше, на этих 16 кэширующих серверах (8 на ДЦ) настроена в nginx балансировка по 2 стораджам из своего ДЦ + 2 стораджа из второго ДЦ указаны с опцией backup. Если ответ с ошибкой или кончился таймаут (специально поставлен небольшим) — отправляем запрос на другой сторадж. Стораджи отдают в день до 4 ТБ за счет кэширующего слоя, а клиентам уходят 14 ТБ.
В такой схеме спокойно живется как при отказе любого сервера, так и при недоступности одного ДЦ. Небольшая часть клиентов при сбоях увидит или небольшое повышение времени ответа, либо недоступность не более 1-2 мин. Ручные действия не требуются, в PagerDuty присвоен низкий приоритет на алерты. Используемое ПО — только бесплатный nginx, за Route 53 — несколько десятков $ в месяц.
Не использую блокировщики, потому что нет доверия создателям расширений браузера — на чем их только уже не ловили, или сами начинают еще больше данных собирать и сливать, или их репозиторий ломали и заразу подкладывали.
А вообще когда сидишь за VPN другой страны, язык которой не знаешь — реклама идет тоже не рускоязычная, и она не так отвлекает и бросается в глаза, мозг видимо сам фильтрует незнакомые сочетания символов.
Против демонстрации на примере k8s ничего не имею, всё-таки это сейчас самый популярный инструмент, а само описание пунктов 13-16 легко натянется и на другой и останется верным.
А вот пункты 17-19 это уже что-то из разряда IBM Cloud only, к ним как раз больше всего вопросов. Но надо понимать что раз статья из блога IBM Cloud — значит и писать они будут про себя.
Верно, тоже ей пользовался, но неоднократно видел мнение что upsdiag правильно работает только со старыми моделями, а при использовании на новых может напортачить записав не то и не туда.
При подключении по rs232 (на самом деле не совсем, нужен специальный кабель apc) — из терминала есть команды для этого, либо есть софтина apcfix для win, которая отправку этих команд в gui обернула (http://apc-fix.com/apcfix).
На APC по поводу battery runtime — достаточно корректно работает на новом ибп после покупки, отслеживает время работы без батарей от полного заряда до низкого уровня напряжения, при определенном уровне нагрузки, и соответственно пишет прогнозируемое время работы от батарей в регистры (которые в обычном режиме работы могут только уменьшаться).
Проблемы начинаются после самостоятельной замены батарей (хоть кто-то здесь возил ибп в СЦ schneider-electric за этим? не думаю). Так вот после простой замены — значения регистров сами не сбрасываются, а остаются такими, какие были на старых батареях перед смертью. Именно в этот момент показатель прогнозируемого времени работы от батарей и начинает показывать погоду на Марсе. Чтобы восстановить нормальное функционирование необходимо делать сброс регистров и последующую калибровку — регистры перезаписываются на максимальное значение, батареи заряжаются до 100% и не менее 12 часов, затем подключается нагрузка не менее 40% от номинала ибп, и начинается работа на батареях, разряд до низкого уровня напряжения. По завершении алгоритм ибп сможет примерно рассчитать прогнозируемое время работы, запишет регистры, а показания станут более достоверными. Такую процедуру придется проводить при каждой замене.
Если речь идет про отчуждаемый сервис от остальной инфраструктуры заказчика — заказчик выделяет разработчику отдельный пул ресурсов (например группа виртуалок у облачного провайдера), развертыванием и сопровождением полностью может заниматься разработчик.
Если сервис интегрируемый и неотчуждаем от инфраструктуры заказчика — то развертывание осуществляется заказчиком, а разработчик просто не реализует этап Continuous Deployment, т.е. делает всё вплоть до поставки готового артефакта заказчику.
Странным выглядит предложение конвертить yaml в json для чтения, а не наоборот. Ведь миссия yaml как раз в повышении человеко-читаемости. И на мой взгляд он хорошо справляется с этим, попробуйте прочитать или написать с нуля без IDE — xml, json и yaml.
Вот видимо потому и цифры у mysql и clickhouse похожие, что не используется преимущества из OLAP модели.
Может под OLAP данные не менялись, и в тот же кликхаус данные писались также как в mysql — в одной строке одна метрика.
По идее в этом случае нужно писать в одну строку — все метрики из одного источника за один timestamp, по колонкам.
eapotapov, как было?
Заинтересовался заголовком, зашел в статью, прочитал, закрыл. Посмотрел на заголовок еще раз. Так и где здесь про Highload то?
Наглядно, полезно. Спасибо!
Аналогичную картину можно наблюдать на балансировщике, когда бэкенд завален работой и время обработки запросов уходит до таймаутов — на балансировщике наблюдается стремитпльный рост количества открытых соединений и запросов в секунду, хотя клиентов больше не стало — просто запросы приходят и копятся, т.к. ждут ответа.
Я потому и упомянул, что для доверия в подобной системе нужно сразу иметь открытость by design, распределенную обработку и хранение, и доверие на основе математики, криптографических подписей и блокчейна, а не на слепом авторитете.
Нет. Но реализована система электронного голосования, использующаяся уже более 10 лет — https://ru.wikipedia.org/wiki/Электронное_голосование_в_Эстонии
Я не в курсе их политических реалий, а имел ввиду чисто техническую составляющую, про которую на Хабре в том числе писали.
В текущей ситуации доверять власти что она хочет и может провести выборы честно — всё равно что садиться играть с шулером, надеясь на то что он джентльмен.
Особенно учитывая, что задействованные люди — находятся в крайне зависимой и управляемой позиции от власти.
Система электронного правительства и голосования по типу Эстонии (для большего вовлечения людей в процесс выборов, а также для избежария ручного труда подчиненных людей) + opensource софт приложения и системы голосования + работа системы прдсчетов по принципам децентрализованности и распределенных систем + криптография на каждом этапе + распределенный блокчейн в качестве хранилища результатов. И затем привлечение мировой экспертизы для проверки работы такой модели и ее математического доказательства. И тогда может быть мы сможем доверять получаем результатам, и сможем проверить и посмотреть цифры прямо у себя на устройстве, а не с сайта под чужим недоверенным управлением.
Интересно насколько Virtuozzo 7 может решить описанные здесь проблемы? Ведь под капотом там те же технологии, а в преимуществах должен быть как раз удобный способ работы с виртуальными машинами и контейнерами в едином интерфейсе. Есть у кого-нибудь опыт эксплуатации?
Я застал OS/2 на банкоматах, только не на тех что в поле (эти были все на Windows XP, и только самые новые — на Windows 7), а на использовавшемся в качестве диагностического стенда для различных модулей. Т.к. для тех моделей банкоматов родной системой была именно OS/2, и возможности имевшегося в ней софта для диагностики были более детальными, чем в версии под Windows XP.
При этом для сборки этого стенда под диагностику, приходилось использовать образ диска, крайне предусмотрительно снятый с одного из последних живых и не обновленных банкоматов с этой системой. И заводилось всё это дело только на системниках с Pentium 3, на IDE дисках размером не более 20Гб (еще и не любого производителя).