Как стать автором
Обновить
36
0

Профессиональный зануда

Отправить сообщение

Тестирование MySQL на ARM-архитектуре

Время на прочтение11 мин
Количество просмотров7.4K


Привет, Хабр!

Мы в ECOMMPAY, помимо прочего, очень любим MySQL и «железные» серверы. MySQL используется как основная СУБД для нашего прода, и, кажется, мы умеем готовить её хорошо для высоких нагрузок. Так же хорошо (а может, и лучше) мы умеем работать с baremetal: они понятно масштабируются, управляются, имеют предсказуемую производительность и стоимость владения. Но кроме эксплуатации, где всё должно быть надёжно и стабильно, есть место и R&D: а как наша нагрузка будет работать в облачной среде, и сколько это будет стоить? А что насчёт альтернативных привычной для многих «Intel x86-64» платформ?

Много копий сломано в борьбе между сторонниками флагманских линеек процессоров компаний Intel и AMD — эта музыка будет вечной, а успехи семейства EPYC только добавляют масла в огонь. Но AMD и Intel выпускают процессоры на давно известной архитектуре x86, от которой больших сюрпризов ждать не приходится. Другое дело ARM — относительно новый игрок на серверном рынке. Тут как раз удачно вышел Graviton2 — второе поколение процессоров от Amazon, которое специально разработали и выпустили для использования в AWS, и мы не удержались.

Когда у AWS появились инстансы на ARM, они наделали много шума. Холодные, быстрые, дешёвые… выберите любые два три. В презентациях AWS и партнёров за последнее время появились результаты тестирования в синтетических бенчмарках и реальных приложениях, которые показывают новую платформу если не превосходной, то, как минимум, перспективной. Но ведь не всегда условия бывают идеальными? В продакшене работает очень разный код, написанный в разное время. И далеко не факт, что именно ваша нагрузка будет работать в новых условиях лучше, чем на привычным x86.

Вот и проверим.
Читать дальше →
Всего голосов 15: ↑15 и ↓0+15
Комментарии18

«В чём сила, брат?», или зачем нужен Источник Правды

Время на прочтение8 мин
Количество просмотров4K

Вас когда-нибудь будили по алерту в 2 часа ночи, и вы бежали поднимать упавший сервер, полчаса дебажили, подняли, а потом выяснялось, что это был не тот сервер? Потому что тот, который нужно, стоял рядом, а вы подняли старый, который выключили специально, и всё окончательно сломали…Или вы послали инженера в ДЦ переткнуть патчкорд, диск поменять... А он смотрел не в ту табличку и менял не тот диск? Или ваш сетевой инженер ошибался IP-адресом и обнулял не ту стойку? Или вообще выключал не тот ДЦ?

Все эти случаи, помимо чисто человеческого фактора, происходят, когда вокруг нас либо недостаточно правды, либо слишком много информации. У нас есть Вики, Git, эксельки, блокнот, а еще инженер Вася, который знает то, чего не знает никто другой. Чтобы избавиться от этой боли, я расскажу, как навести порядок в описании инфраструктуры и создать свой Источник Правды (Source of Truth), достоверный и актуальный.

Читать далее
Всего голосов 11: ↑10 и ↓1+9
Комментарии8

Закупки как сервис

Время на прочтение11 мин
Количество просмотров4.7K

Всем привет!

Меня зовут Алексей, и я работаю  в компании ecommpay IT. Мы пишем и эксплуатируем ПО для эквайринга и процессинга карточных платежей. Если совсем по-простому - мы делаем так, чтобы оплачивать товары в Интернете было удобно, быстро и безопасно.

Я было хотел написать, что в компании я решаю проблемы, как Мистер Вульф из известного фильма, но вовремя вспомнил недавние подкаст и статью Василия Пантюхина, и решил, что надо быть скромнее.

Пусть это будет Максми Поташёв Александр Друзь.

Почему? потому что чаще всего я по работе отвечаю на три простых вопроса:

Что из оборудования или софта было заказано в текущему/прошлом месяце/квартале? Что ещё можно/нужно заказать в этом квартале, чтобы уложиться в бюджет?
Где деньги сейчас находится заказанное оборудование? А что есть на складе?
Когда приедет/будет оплачено то, что заказали?

Кому-то может показаться, что это абсолютно скучная бумажная работа, и инженерам тут делать нечего, но это будет только долей правды ;).

Зачем инженеру заниматься закупками?
Всего голосов 23: ↑22 и ↓1+21
Комментарии9

Сетевики (не) нужны

Время на прочтение11 мин
Количество просмотров30K
На момент написания этой статьи поиск на популярном работном сайте по словосочетанию «Сетевой инженер» выдавал около трёхсот вакансий по всей России. Для сравнения, поиск по фразе «системный администратор» выдаёт почти 2.5 тысячи вакансий, а «DevOps инженер» — почти 800.

Значит ли это, что сетевики более не нужны во времена победивших облаков, докера, кубернетеса и вездесущего публичного вайфая?
Давайте разбираться (с)


Читать дальше →
Всего голосов 46: ↑44 и ↓2+42
Комментарии63

Juniper SRX и Cisco ASA: серия очередная

Время на прочтение10 мин
Количество просмотров8.7K
Первый раз строить IPSec между Juniper SRX и Cisco ASA мне довелось ещё в далёком 2014 году. Уже тогда это было весьма болезненно, потому что проблем было много (обычно — разваливающийся при регенерации туннель), диагностировать было сложно (ASA стояла у нашего заказчика, поэтому возможности для дебага были ограничены), но как-то это работало.

image

С той поры и рекомендованный JunOS для SRX обновился на 15.1 (для линейки SRX300, по крайней мере), и ASA научилась в route based IPSec (c версии софта 9.8), что несколько упрощает настройку. И вот на текущей работе не так давно представился шанс снова собрать такую схему. И снова неудачно — при регенерации туннель благополучно падал (и не всегда поднимался без ручного рестарта). И снова в логах тишина и непонятки, а т.к. ASA находилась у нашего партнёра, то и дебажить, соответственно, не было никакой возможности.

И вот теперь представился случай собрать схему, при которой обе стороны (и SRX, и ASA) находятся под нашим управлением, соответственно, поиграться можно на славу.
Читать дальше →
Всего голосов 9: ↑9 и ↓0+9
Комментарии13

Экскурсия в салатовых тонах

Время на прочтение9 мин
Количество просмотров6.9K

Самая главная транспортная проблема в Питере — это мосты. Ночью из-за них приходится убегать из кабака, не допив пиво. Ну или платить за такси в два раза больше обычного. Утром — тщательно рассчитывать время, чтобы как только мост свели, ты ловким мангустом успел на вокзал. Вариант "ночевать где-нибудь в центре, рядом с вокзалом" мы не рассматриваем, как идеологически вредный.


..."Сапсан", уходящий в 5:30, придумали люди, которые ненавидят сов. Нет, разумеется, очень удобно оказаться в Москве в девять утра, а Питер безумно прекрасен во время белых ночей, но в половину пятого, когда я сел в такси, мне хотелось повернуть голову на 270 градусов тому жаворонку, который придумал этот утренний поезд.



"Все хорошие датацентры похожи друг на друга" — думал я, когда узнал, что нас пригласили в гости ребята из DataLine.


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

Читать дальше →
Всего голосов 23: ↑23 и ↓0+23
Комментарии7

Миграция Xenserver 7 на linux raid

Время на прочтение4 мин
Количество просмотров11K
Xenserver недавно обновился до седьмой версии и я, конечно же, не смог пройти мимо.

Среди бросающихся в глаза плюшек (помимо миграции на CentOS 7) — другая разбивка диска с монтируемым отдельно /var/log (наконец-то) и увеличенным до 20 гигов корнем (алиллуйя!).
Но вот делать при загрузке RAID любого уровня он так и не умеет. А значит, нужно опять мигрировать уже установленную систему.

image

Благо, если XenServer только-только установлен, то это не так страшно.

Читать дальше →
Всего голосов 9: ↑9 и ↓0+9
Комментарии21

Сказ о том, как мы отечественного производителя поддерживали

Время на прочтение8 мин
Количество просмотров82K


Если долго мучиться — что-нибудь получится!
(с) народная мудрость

Настало время увлекательных историй, %username%!

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

В силу своей профессиональной деятельности, нам приходится работать с разными операторами связи. Практически все они — федерального уровня, либо их «дочки» в странах СНГ. Одной из таких компаний является… Пусть он будет Z.
История взаимоотношений с ним давняя и коллеги, наверное, расскажут много интересного. Но это как-нибудь потом, а пока расскажу свою историю я.
Требования к безопасности в этой компании серьезные — положение обязывает (А еще 152-ФЗ «О защите персональных данных»). Причем если раньше требования были драконовские (в духе «Миссия невыполнима»: изолированное помещение, сканер сетчатки, автоматчики...), то сейчас свелись к просто строгим: индивидуальные учетки и шифрованные каналы связи между нами и заказчиком. Шифрование — ГОСТовское, никакого вам буржуйского заграничного IPSec. Рынок таких решений мал, поставщиков — раз-два и кончились. Реализация… ну не Checkpoint и не Cisco, но терпимо.

Но это была присказка, а за сказкой прошу под кат!
Читать дальше →
Всего голосов 31: ↑24 и ↓7+17
Комментарии39

Настойка можжевельника: готовим Juniper SRX. Часть 3: Virtual Routers

Время на прочтение6 мин
Количество просмотров20K
juniper — можжевельник (англ.)

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

image

Содержание:

Часть 1: Знакомство
Часть 2: IPSec
Часть 3: Virtual Routers

В Juniper есть тип сущностей Routing Instance, предназначенный для манипуляций с трафиком (маршрутизации и инкапсуляции). RI позволяют «разделить» один роутер на несколько поменьше, при этом каждый instance будет обрабатывать трафик «по-своему», независимо от других и с разными возможностями. Это полезно для организации всевозможных VPN, когда нужно изолировать друг от друга нескольких клиентов и разрулить их по разным правилам. При этом информацией о VPN можно обмениваться с другими роутерами (например, при организации MPLS VPN).
Читать дальше →
Всего голосов 8: ↑8 и ↓0+8
Комментарии0

Траблшутинг ipsec-туннелей в Juniper

Время на прочтение3 мин
Количество просмотров14K
Статей по настройке IPSec на Juniper SRX уже появилось несколько: раз, два, три. Но я бы хотел отойти чуть в сторону, и поговорить о том случае, когда что-то пошло не так.

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

Что оказалось полезным для меня:
Описание ошибок VPN — довольно подробная табличка при анализе логов. Так же информацию можно посмотреть здесь (удобно сгруппировано по типам VPN-туннелей).

Ну а самая мякотка под катом.
Читать дальше →
Всего голосов 6: ↑5 и ↓1+4
Комментарии7

Настойка можжевельника: готовим Juniper SRX. Часть 2: IPSec

Время на прочтение8 мин
Количество просмотров23K
Не так давно мы пощупали немножко Juniper SRX, настроили его , и собрали отказоустойчивый кластер. Теперь начнем поднимать на нем «боевые» схемы, ради которых все и затевалось.
Например, соберем мысленно вот такую схему:


На схеме видим центральный офис и подключенную к нему ноду — это может быть как филиал, так и какой-то удаленный заказчик/клиент, для связи с которыми требуется защищенное соединение. Разумеется, их может быть несколько (об этом ниже). Способ связи при этом нам абсолютно не важен: хоть Интернет, хоть «темное волокно» — данные все равно нужно шифровать, чтобы свести к нулюминимуму риск их утечки. И чем выше стойкость шифра и совершенней способ фильтрации, тем целее будут нервы администратора (как вы, наверное, знаете, сисадмин, как и любая замкнутая система, всегда стремится к состоянию покоя).

Сегодня мы будем поднимать IPSec-туннели
Всего голосов 9: ↑7 и ↓2+5
Комментарии19

Настойка можжевельника: готовим Juniper SRX. Часть 1

Время на прочтение7 мин
Количество просмотров30K
juniper — можжевельник (англ.)

Намедни в мои цепкие лапы попали два Juniper SRX 550. Попали не просто так, а для организации надежного ipsec и NAT-шлюза, а также OSPF-роутера. Ну а так как главное для нас — надежность, то именно с нее и начнем.

Для того, чтобы обеспечить отказоустойчивость сервисов, критично важные узлы обычно дублируют. Для ЦОДов это уже практически стандарт — N+N или хотя бы N+1. При этом устройства могут работать как независимо друг от друга, так и в кластере. Для обоих типов есть свои плюсы и минусы, но если нужен не просто роутинг/свитчинг, но нечто более «интеллектуальное» (например, те же NAT или IPSec), то без кластера тут точно не обойтись. Так что при плановом апгрейде в качестве замены Cisco 7201 рассматривались именно роутеры, способные работать в кластере. В связи с этим ASR 1k отправился лесом (как и ISR), ASA не рассматривалась (потому как готовить ее не умею), а VSS из Cat6503 — это уж слишком жирно и в плане цены, и в плане съедаемой электроэнергии.

Герой нашего рассказа. (Здесь и далее — картинки с официального сайта Juniper)
Читать дальше →
Всего голосов 11: ↑8 и ↓3+5
Комментарии28

Как отравить кошку? Детективная история со счастливым концом

Время на прочтение3 мин
Количество просмотров55K
Устраивайся поудобнее, мой читатель. Сегодня я расскажу тебе увлекательную историю.

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

Первая мысль после перезагрузки роутера: какой-то шутник решил запустить очередную убер-программу. Ну, или чей-нибудь ноут сошел с ума – тоже бывает. Однако пристальное изучение трафика (netflow, прослушка tcpdump-ом на предмет хитрого бродкаста) ничего не дало. Более того, шторм-контроль на клиентских портах не срабатывал.

А тем временем, роутер, проработавший после ребута едва ли пять минут, снова завис. Прошу заметить, в самый разгар рабочего дня. «К счастью», телефония шла через этот же роутер, и только это спасло нас от воплей огорченных коллег:).
Читать дальше →
Всего голосов 156: ↑142 и ↓14+128
Комментарии93

MPLS и VPLS на Mikrotik

Время на прочтение9 мин
Количество просмотров134K
С одной стороны, желание несколько странное — организация «серьезного» MPLS/VPLS на дешевом железе типа Mikrotik. С другой стороны — за 70 баксов (1500-2000р) за младшую модель RB/750(GL) мы получаем PE/CE-устройство, умеющее (помимо прочего) L2VPN/L3VPN поверх MPLS-среды и способное прокачать через себя порядка 70 мегабит дуплекса (на больших пакетах).
Mikrotik RouterOS умеет как MPLS (L3VPN, Traffic Engeneering), так и L2VPN (l2circuit aka VPWS, VPLS), что покрывает практически все возможные задачи (учитывая производительность железа, разумеется).

Интересно? Прошу под кат!
Читать дальше →
Всего голосов 15: ↑14 и ↓1+13
Комментарии16

Информация

В рейтинге
Не участвует
Откуда
Санкт-Петербург, Санкт-Петербург и область, Россия
Дата рождения
Зарегистрирован
Активность