Сообщество - Лига Сисадминов

Лига Сисадминов

2 416 постов 18 934 подписчика

Популярные теги в сообществе:

66

Нужен совет по доделке самоделки

Коллеги и просто сопикабучане, всех неистово приветствую и взываю к великой силе Пикабу, ибо на чудеса она способна немыслимые!


Соорудил я коллегам удобную штуковину для хранения батареек, ну как соорудил -- придумал и начертил, в производство отдал своему куда более пряморукому товарищу, и совместными усилиями получилось нечто следующее (переднее стекло демонтировано для удобства отладки):

Принцип работы достаточно очевиден)

А теперь, уважаемые знатоки, внимание вопрос.

С типоразмером АА проблем не возникает и работает все, как часы, а вот их младшие товарищи из соседнего отсека в одном из примерно 3,5-4 случаев выдают следующую ошибку:

Пытался фиксить рандомным изменением места вклейки костылей спичек -- с мизинчиковыми не помогает(

Прошу свежих идей в комментах, а никнейм того, чье предложение сработает -- разместим на изделии))


Всем солнечной пятницы и по возможности нерабочей субботы ;-)


P.S.: вопрос конечно не слишком сисадминский, но наш брат смышлен, креативен и смекалист, а посему пост публикую в сообществе 

Показать полностью 3
12

Отказы ИС 2. Reddit и миграция бэкенда

Отказ произошел 11 августа 2016 года и вывел из строя Reddit в общей сложности на 3 часа.

Оригинал статьи можно найти тут.

Общие сведения о проблеме. 11 августа Reddit был не доступен в период с 15:24 до 16:52 (это и все нижеследующее премя представлено в PDT), а в период с 16:52 до 18:19 имел проблемы с производительностью. Проблема затронула все официальные платформы Reddit и API, обслуживающие сторонние приложения. Простой был вызван ошибкой, возникшей во время миграции критической составляющей бэкенда. В результате инцидента данные потеряны не были.

Причина ошибки и ее исправление. Reddit использует Zookeeper для мониторинга работы серверов. Также используется система автомасштабирования для обеспечения необходимого числа серверов, зависящего от нагрузки на систему.

Часть обновлений инфраструктуры включала в себя миграцию Zookeeper на более современную платформу, внутри облаков Amazon. Так как система автомасштабирования получает данные напрямую из Zookeeper, то на время миграции она была отключена, чтобы у нее не возникало путаницы в том, какие сервера должны быть доступны. Однако, в 15:23 система была неожиданно запущена менеджером пакетов, заметившим ручное изменение конфигурации. За 16 секунд запущенная система, выполнив чтение данных частично перенесенного Zookeeper, отключила множество серверов, обслуживающих основной сайт, API и системы кэширования.

В 15:24 инженер Reddit заметил, что серверы были отключены, и в 15:47 перевел сайт в "нерабочее состояние", чтобы восстановить работу всех серверов. К 16:42 все сервера были запущены. Однако все кэши в это время были пусты, что привело к увеличению нагрузки на базы данных и, как следствие, к снижению производительности. В 18:19 время отклика было в норме и все системы работали нормально.

Профилактика. Модернизация инфраструктуры будет порождать различные типы миграции серверов. Так как вышеописанный сбой был связан с уникальной и выскорисковой миграцией, то специалисты Reddit не предполагают, что имевшая место комбинация сбоев в будущем в точности повторится. Однако, они определили следующие несколько улучшений, которые должны повысить общую устойчивость системы к ошибкам, возникающих при критических миграциях:

- сделали систему автомасштабирования менее агрессивной, уменьшив количество серверов, которые она может единомоментно остановить;

- изменили регламент миграций так, чтобы критические операции выполнялись инженерами в паре;

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

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

Показать полностью

Разработчикам вход воспрещён: 7 кейсов автоматизации задач эксплуатации на Python

Разработчикам вход воспрещён: 7 кейсов автоматизации задач эксплуатации на Python

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


С кастдевов по курсу Слёрм «Python для инженеров» получилась интересная подборка практических кейсов автоматизации задач эксплуатации на Python в зарубежных и наших компаниях.


Кейс первый: облачный.

Компания активно пользуется облаком и тратит 2 миллиона рублей в месяц на инфраструктуру в AWS. Можно написать инструмент на Python, который будет анализировать и отключать «холостые ресурсы». Это позволит сократить расходы на 40-50% или около 12 миллионов рублей в год.


Кейс второй: экзотический.

У компании много экзотических сервисов, которые необходимо мониторить. Можно написать несколько Prometheus-exporter'ов на Python, что позволит эффективнее мониторить приложения и свести к минимуму простой платформы. Актуально для Fintech, ADtech, крупных медийных, социальных и сервисных площадок.


Кейс третий: Ansible.

Часто документация о серверах ведётся в Jira. Иметь единый источник информации хорошо, но переносить серверы из Jira куда-либо - неудобно. Пример с Ansible. Можно держать честный инвентори в Ansible-репозитории и по завершении деплоя обновлять страницу в Jira, записывая какие сервера для каких целей используются. Или можно с помощью Python генерировать status page - писать, какие версии каких сервисов сейчас задеплоены в каждом environment.


Кейс четвёртый: Chef.

У меня был случай, когда я писал сводную систему chef-opscode + AWS + [webazilla.com](http://webazilla.com/), чтобы понимать за что и сколько мы платим. Chef в качестве глобального инвентори + базовая статистика по загрузке системы + провайдерские API.


Кейс пятый: lint-тесты.

В практике был опыт написания на Python lint-тестов для ansible и kubernetes. Они позволяли проверять на наличие обязательных параметров, которые были стандартными в рамках компании. Без автоматизации проверяли руками и глазами, что конечно же намного дольше и неэффективней.


Кейс шестой: zabbix.

Была написана прослойка между системой мониторинга и внутренним таск-менеджером. Скрипт получает сырые алерты от zabbix, обрабатывает их в соответствии с определенной логикой и создает конкретную задачу в трекере. Дежурные специалисты оперативно получают точную информацию и не тратят время на выяснение «очага возгорания» среди сотен клиентских серверов.


Кейс седьмой: саппорт.

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

Это занимало в среднем 5 минут на одного клиента, аналогичных задач было 7-10 штук в день. После автоматизации процесса с помощью Python затраты на задачу сократились до 15 секунд. Экономия в месяц — примерно 23 часа. В качестве бонуса увеличилась лояльность клиентов, ведь теперь их запросы обрабатывались в считанные секунды.

Показать полностью 1
214

Настройка SOCKS5 на Mikrotik

Вот так, тихо, без оваций и громких речей на Mikrotik завезли поддержку Socks5. Скромная строчка в релизе 6.47 - added support for SOCKS5 (RFC 1928) и ожидания пользователей mikrotik наконец то сбылись.


Краткая справка для тех кто не в теме:

SOCKS это разновидность прокси-сервера. Используется например для доступа к сайтам торрентов. В отличие от HTTP-прокси-серверов, SOCKS передаёт все данные от клиента, ничего не добавляя от себя, то есть с точки зрения конечного сервера, данные, полученные им от SOCKS-прокси, идентичны данным, которые клиент передал бы напрямую, без проксирования.

Отличие SOCKS 4 от SOCKS 5 состоит в том, что SOCKS 5 имеет поддержку сетевого протокола UDP, может работать в схемах со строгой аутентификацией, а также поддерживает сетевую адресацию IPv6 (которую планируют внедрить в будущем, так как современная IPv4 скоро исчерпает все свои возможности). SOCKS 5 дал возможность работы через прокси, даже тем программам, которые изначально не имели такой возможности.

Проще говоря соксы 5 продвинутей.


Настройка Socks5 сервера проста и не затейлива.

Порт я обычно меняю на не стандартный, чтобы хоть чуть-чуть снизить нагрузку от сканящих все подряд ботов. Выбираем версию протокола 5 и метод аутентификации по паролю:

Добавляем пользователя с паролем и на этом базовая настройка Socks5 сервера завершена.

Хотя я обычно добавляю еще ограничение на доступ по IP:

Остается добавить правило в файрволл:

ip firewall filter add chain=input protocol=tcp dst-port=7777 action=accept comment="SOCKS5 TCP"

add chain=input protocol=udp dst-port=7777 action=accept comment="SOCKS5 UDP"или в winbox

Для работы с проксей в хроме использую расширение Proxy Switcher, но он почему то не хочет использовать авторизацию.

Показать полностью 4
189

Тру Vpn за 4 бакса в месяц)

Привет, дорогой Пикабу!


Здесь произойдёт краткий(насколько это возможно) раccказ о том как я строил настоящий впн за недорого.


Как выглядит ТЗ:

– возможность создавать несколько учётных записей пользователей

– высокая скорость доступа (в рамках бюджета)

– безопасность данных (как настроишь, так и полетит)

– бюджет реализации 4$ :-)


Что мне для этого понадобится?

Совсем не много:

1. Хостинг провайдер с VPS, в моём случае это OVHcloud

(уважаемые читатели могут выбрать любой хостинг!)

2. Необходим облачный MicrotikCHR (Кликабельно)

3. VPS-сервер c предварительно установленной Ubuntu 20.10

4. Множко времени для настройки и тестирования


Процесс заказа VPS я пропущу, много бесполезной информации и куча лишних скриншотов!

Один важный момент связан с выбором локации хостинга VPS, чем дальше от меня сервер, тем выше латенси/ping, важно для онлайн игр, но в моём случае особой роли не играет.

После покупки VPS-ки мне на почту упало письмо с доступами в машине.

Залетаем в ssh, меняем сгенерированный хостингом пароль, добавляем свой публичный ключ для root, меняем hostname, обновляем, устанавливаем unzip перезагружаем.


На этом базовая подготовка VPS закончена, дальше интересней.

1 - Необходимо создать временный раздел для хранения образа MicrotikCHR

mount -t tmpfs tmpfs /tmp/

2 - через wget скачать образ MicrotikCHR raw по ссылке, что приведена выше

wget https://download.mikrotik.com/routeros/6.47.9/chr-6.47.9.img...

3 - распаковать скачанный архив


unzip chr-6*

4 - просмотреть разделы на диске, это необходимо, для того чтобы знать на какой из их,  записать образ RoS CHR


fdisk -l

· в моём случае это - /dev/sda: 20GiB (Основной раздел диска)

· если ошибиться с выбором раздела, прийдётся вернуться к установке ОС и повторной первичной настройке

5 - Записать образ с помощью dd на нужный раздел

dd if=chr-6.47.9.img of=/dev/sda bs=4M oflag=sync

· if= то что ми пишем
· of= то куда пишем
· bs= размер блока записи
· oflag= опция дополнительных параметров, sysnc - дополняет сектора значениями NUL

6 - Перезагрузится, обычный reboot не сработает, потому:

echo 1 > /proc/sys/kernel/sysrq
echo b > /proc/sysrq-trigger

Дальше перехожу в веб-интерфейс хостинга и задаю пароль для пользователя admin через KVM (по умолчанию логин Mikrotik, admin без пароля)

/user set [find name=admin] password=SupeR_stronG_paSs-228

Параллельно добрые люди с ботами хотят взломать мой облачный роутер :-)

Дабы избежать неловких ситуаций, следует ограничить доступ к сервисам ssh, winbox , остальные отключить.


IP - Services

Теперь предстоит самое интересное, а именно настроить l2tp/IPSec


1. Ip - pool


– name : l2tp=pool

– addresses : 192.168.20.2-192.168.20.200

– next pool : none

2. PPP - Profiles / Создать профиль для l2tp туннеля


– name : l2tp-profile

– local address : l2tp-pool

– remote address : l2tp-pool

– DNS servers : 1.1.1.1 (можно использовавать любые)

3. PPP - Secrets / Создать профиль пользователя

– name : vpn-user001 (уникальность имён приветствуется)

– password : пароль умеренной сложности

– service : l2tp

– profiles : ранее созданный l2tp-profile

4. PPP - Interface - L2TP Server


– Enable

– default profile : ранее созданный l2tp-profile

– authentification : оставить только (mschap2)

– use ipsec : required

– ipsec secret : не самый простой Shared Secret

5. IP - IPSec - Proposals


– name : default

– auth algorithms : sha1

– encr. algorithms : aes-128 cbc / aes-192 cbc / aes- 256 cbc

– pfs group : modp 1024

· этот конфиг создается по умолчанию, но всё же стоит проверить ;-)

6. IP - FireWall - NAT

· без nat, подключение произойдёт, но сети не будет

– nat rule : srcnat

– out. interface list : all

– переходим на вкладку Action

– action : masquerade

7. Простая настройка firewall


· буду приводить только консольные команды без скриншотов (ну ладно будет один финальный в конце ;-) )

· В терминале через winbox или ssh

/ip firewall filter

· добавить правила fasttrack connections

add action=fasttrack-connection chain=forward connection-state=\
established,related
add action=fasttrack-connection chain=forward connection-state=\
established,related protocol=tcp
add action=fasttrack-connection chain=forward connection-state=\
established,related protocol=udp
add action=accept chain=forward comment="FastTrack Connection" \
connection-state=established,related

· Правила для established, related + открыть порты для l2tp (500,1701,4500)

add action=accept chain=in connection-state=established,related
add action=accept chain=input comment="Port Access" dst-port=500,1701,4500 \
in-interface=ether1 protocol=udp

· разрешить ping (icmp)

add action=accept chain=in in-interface=etgher1 protocol=icmp

· остальное drop

add action=drop chain=forward connection-state=invalid
add action=drop chain=input connection-state=invalid
add action=drop chain=in

8. получить лицензию на CHR

- Зарегистрироваться на оф.сайте Mikrotik

- Зарегистрировать CHR (после триального периода роутер не превращается в тыкву, если его не обновлять, продолжит работать на полной скорости даже после истечения лицензии)


system - license - renew license


- account : логин в учётную запись на Mikrotik.com

- passwrod : пароль от учётной записи на Mikrotik.com

А в личном кабинете видно временную лицензию

И на финал, тест скорости ;-)

Из минусов, не гигабит)


Крайне приветствую комментарии и предложения по теме!)

Показать полностью 17
7

Отказа ИС 1.1. Amazon (DynamoDB) - сопутствующие проблемы

В прошлом посте (Отказы ИС 1. Amazon (DynamoDB)) был описан отказ БД DynamoDB из-за ошибки службы управления метаданными. Однако отказ сбоем только в DynamoDB не ограничивается. Ниже описаны проблемы смежных сервисов Amazon.

Simple Queue Service (SQS). На ранних этапах сбоя DynamoDB, SQS работал с повышенным фоном ошибок и с немного большей задержкой. Amazon SQS использует в своей работе DynamoDB для хранения очередей. Когда информация об очереди закэширована в SQS и не доступна напрямую для API непосредственной отправки/приема сообщений, кэш часто обновляется, чтобы корректно отразить операции создания, удаления и изменения, выполняющиеся в инфраструктуре Amazon. Когда DynamoDB перестал блокировать трафик в 05:45 PDT (с тем, чтобы дать возможность сервису метаданных восстановиться), SQS не мог считывать данные из БД, что привело к значительному повышению фона ошибок. Когда в 07:10 PDT трафик стал восстанавливаться, сервис очередей восстановился, данные в очередях в результате инцидента потеряны не были.

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

EC2 Auto Scaling. Между 02:15 и 07:10 API сервиса отдавала большое число ошибок. С 07:10 до 10:52 в EC2 наблюдались существенные задержки при выполнении нового подключения, либо отключении старого. Уже имевшиеся подключения продолжали работать корректно в течение всего инцидента.

Сервис хранит в DynamoDB информацию о группах и конфигурацих запуска. С момнета начала инцидента EC2 не мог обновлять внутреннюю таблицу данных при вызове его API. Когда DynamoDB было восстановлено, началось восстановление работы сервиса, которое не было закончено из-за накопившихся за время инцидента не обработанных активностей. Запуск и остановка сервиса осуществляется в фоновых процессах. В течение инцидента накопилось большое количество активностей, связанных с вышеупомянутым фоновым планировщиком. Эти процессы обрабатывались до 10:52.

Помимо мероприятий, сделанных командой DynamoDB, заключавшихся в обеспечении быстрого восстановления при образовании большого лога необработанных запросов, Amazon также изменил подход к разделению работ над серверами EC2 (чтобы большее их число можно было выполнять в параллельном режиме), внедрил механизмы удаления старых активностей и увеличил мощность серверов для обработки запоросов.

CloudWatch. Начиная с 02:35 сервис метрик Amazon - CloudWatch, - начал регистрировать задержки, отсутствие метрик EC2, а также возросшее число ошибок. CloudWatch использует внутреннее хранилище для добавления информации о членстве в группе автомасштабирования во все входящие запросы сервиса EC2. С 02:35 до 05:45 ошибки в DynamoDB обуславливали нестабильный доступу к метрикам EC2. CloudWatch также заметил ненормально низкую активность метрик других сервисов, использующих DynamoDB, усугбляя  проблему доступа к метрикам.

Далее примерно с 05:51 до 07:10 CloudWatch сообщил о значительно возросшем фоне ошибок вызовов API сервиса PutMetricData, что влияло на все метрики Amazon, а также метрики, созданные пользователями. Ошибки были связаны с доступом к данным о членстве, упомянутым выше. Сервисы CloudWatch восстановились к 07:29.

Для уменьшения влияния DynamoDB на CloudWatch Amazon уменьшил размер пакета до минимально возможного. Также в разработке сервисы быстрой доставки метрик за счет сквозной записи кэшей. Этот кэш должен предоставить возможность получать метрики без их ее сохранения. Кроме того он обеспечит большую защиту данных.

Console. AWS console также работала не стабильно у некоторых пользователей между 05:45 и 07:10. Пользователи, уже зашедшие в консоль оставались подключенными к ней. Те же, кто пытался войти в систему сталкивались с высокими задержками при входе. Это связано было с высокими задержками API, полагавшегося на DynamoDB. Для успешного входа вызов к этому API не обязательно должен пройти без ошибок, но из-за большог таймаута, этот запрос, блокировал процесс входа на десятки секунд.

Таймаут запроса уже был уменьшен и отправлен на тестирование. К сожалению, до начала инцидента новая версия консоли еще не была обновлена на релизе.

P.S. Сбой в системе хранения затронул большое число сервисов, однако, выше приведены основные - т.е. те, которые Amazon сам посчитал таковыми.

Показать полностью
2101

История про вирус-шифровальщик

Впечатлившись рекламой и хвалебными отзывами руководство одной из контор, в которых мне довелось сисадминить, приняло решение о внедрении модного Kerio Control. Сказано – сделано: мечта об удаленном рабочем столе претворилась в жизнь, а трудовые будни окрасились в неожиданно привлекательные тона. Теперь начальство могло преспокойно работать из дома, попивая кофе в трусах.


Беда, как это обычно бывает, пришла, откуда не ждали. Поскольку о таком понятии как VPN ребята слыхом не слыхивали, а о его назначении – и подавно, то, недолго думая, открыли порт удаленного рабочего стола для доступа из любой точки недружелюбного внешнего мира. И, конечно же, при этом пароль администратора на сервере был «12345», его никто не удосужился поменять, да и вряд ли кто об этом задумывался.


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


Работа конторы оказалась парализована, со стороны это всё выглядело следующим образом: все опрошенные старательно отрицают переход по небезопасным ссылкам нигерийских принцев, руководящий состав мечет громы и молнии, часть рядовых сотрудников радуется возможности похалявить, проектный отдел рвёт на себе волосы, логисты нервничают, кадровики хранят отстраненное молчание, и только снабженцы с трудом скрывают довольные ухмылки. Стало очевидно, что без привлечения квалифицированного специалиста дальнейшее функционирование не представляется возможным. Тогда-то меня и вызвали, чтобы поставить извечный русский вопрос: «Что делать и кто виноват?».


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


На кону была не только дальнейшая работа компании, клиентская база и многолетние наработки, но и пресловутая коммерческая тайна. Казалось бы – что такое полмиллиона для преуспевающей столичной конторы с приличным годовым оборотом?


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


От успеха или неудачи в данной ситуации напрямую зависела моя репутация и дальнейшее сотрудничество с компанией, не скупящейся на оплату моих трудочасов. Вариантов у меня было немного. Здраво рассудив, что за спрос денег не берут, решил закинуть удочку злодеям. Написал, мол, деньги не проблема, однако, имеются сомнения в оправданности трат – хорошо бы продемонстрировать способность к расшифровке, вот, хотя бы на этом «совершенно рандомном» файле.


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


А ведь всего этого можно было избежать, если бы VPN вовремя настроили, порты открывали с умом и использовали сложные пароли.


P.S. Прикладываю скрин переписки с злодеями, дабы развеять все сомнения в кото-ламповости истории. В нем видно, что файл они прислали.

Показать полностью 1
19

Отказы ИС 1. Amazon (DynamoDB)

Сегодня речь пойдет о NoSQL базе данных DynamoDB. Текст отчета взят отсюда.

Общие сведения о  DynamoDB. DynamoDB хранит информацию в таблицах, разделенных на части (разделы), в каждой из которых содержится часть всей информации в БД. Эти разделы распределены по множеству серверов для обеспечения быстрого (с малой задержкой) и постоянного доступа к хранящейся информации, а также для целей репликации данных.

Принадлежность разделов к конкретному серверу называется "членством" (membership). Членство некоторого множества таблиц/разделов в рамках одного сервера управляется внутренней службой управления метаданными  DynamoDB. Служба имеет внутреннюю репликацию и запускается в нескольких центра обработки данных (ЦОД). Сервера хранения данных содержат актуальные данные таблицы внутри раздела, а также периодически выполняют проверку того, что разделам определено корректное членство. Они осуществляют такую проверку, связываясь со службой управления метаданными. В ответ на запрос служба получает список разделов и всю связанную информацию из своего локального хранилища, объединяет эти данные в сообщении, передаваемом в последствии на сервер. Сервер хранения также получает сведения о собственном членстве при старте, либо после неполадок сети. После того, как сервер хранения данных закончил обработку собственных сведений о членстве, он проверяет наличие таблиц/разделов в локальном хранилище, создает новые связанные таблицы/разделы и получает данные от других серверов хранения для репликации существующих связанных разделов.

Первоначальная причина отказа. В 2:19 ночи ( PDT - тихоокеанское летнее время, -10 часов от МСК) наблюдалось кратковременное падение сети, затронувшее несколько серверов DynamoDB. Обычно аналогичные падения сети обрабатываются не заметно и без изменения производительности DynamoDB, так как затронутые сервера хранения запрашивают службу управления метаданными сведения о своем членстве, применяют все необходимые обновления и сообщают, что они вновь могут обрабатывать запросы. Если сервера хранения не могут получить информацию назад в течение определенного периода времени, они отправляют повторный запрос о членстве и временно отписываются от обработки запросов.

Основная проблема. Но воскресным утром несколько ответов службы управления метаданными превысили предел времени получения и передачи данных. В следствие чего некоторые из серверов не смогли получить сведения о членстве и отписались от обработки запросов. Увеличение времени ответа было связано с недавней доработкой DynamoDB: в последние несколько месяцев пользователи часто применяли GSI (Globl Secondary Indexes). GSI позволяет обращаться к данным по альтернативным ключам (а не по первичным). Так как GSI является глобальным, он имеет свой собственный набор разделов на серверах хранения, тем самым увеличивая общий размер членских данных. Пользователи могут добавить несколько GSI для одной таблицы, поэтому таблица с большим числом разделов может быстро удвоить или утроить размер таких данных. За счет быстрого применения технологии пользователями для больших таблиц индекс "разделов-на-таблицы" значительно вырос. Из-за больших размеров членских данных время обработки некоторых запросов начало приближаться к пороговым значениям. Amazon не вел мониторинга размера данных о членстве и не имел достаточных мощностей для обработки таких тяжеловесных запросов.

Таким образом, когда в воскресенье после проблем с сетью несколько серверов одновременно запросили свои членские данные, служба управления метаданными обрабатывала тяжелые запросы. Несколько одновременных запросов для таких больших объемов данных привело к еще большему увеличению времени обработки, что привело к отказу  серверов хранения от обработки входящих запросов. Из за высокой нагрузки на службу управления метаданными, она также перестала отвечать на запросы серверов, не вовлеченных в изначальную проблему деградации сети, которые запросили обновление своих членских данных. Многие из этих серверов хранения также стали недоступны. Недоступные серверы продолжали отправку запросов на обновление сведений, сохраняя тем самым высокую нагрузку на службу управления метаданными. Не смотря на то, что многие запросы обрабатывались корректно, работающие сервера, получившие успешный ответ от службы один раз, получали ошибочный ответ в следующий, становясь вновь недоступными. К 2:37 ночи количество ошибок достигло максимума за последние три года, остановившись примерно на 55%.

Предпринятые шаги. Из-за высокой нагрузки Amazon не мог добавить ресурсов к службе. После нескольких неудачных попыток увеличить мощности в 5:06 утра было решено остановить запросы к службе. Это действие уменьшило активность повторных запросов, составлявших существенную часть нагрузки на службу. После того, как служба смогла отвечать на запросы администраторов, Amazon смог значительно увеличить вычислительные ресурсы и возобновить запросы серверов хранения к службе. В 7:10 утра работа DynamoDB была восстановлена.

Количество ошибок значительно  снизилось и составляло теперь 0.15%-0.25%, что считалось приемлемым показателем, хотя и более высоким, чем обычно. В понедельник Amazon начал получать сообщения от пользователей о проблемах с таблицами, застрявшими в режиме обновления или удаления. Проблема заключалась в том, что не смотря на низкий уровень ошибок, отказы был и распределены не равномерно между пользователями и у некоторых из них отказы случались существенно чаще, чем у других. Оказалось, что проблема была вызвана тем, что некоторые из разделов все еще не обрабатывали требуемое количество трафика. Команда администраторов работала осторожно и старательно чтобы восстановить собственные разделы службы управления метаданными и закрыла эту проблему в понедельник.

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

Показать полностью
Отличная работа, все прочитано!