воскресенье, 15 декабря 2013 г.

клиенты-серверы

Читая книгу Робачевского-Немнюгина-Стесик про юниксы, поймал себя на мысли. Раньше, когда речь заходила о клиент-серверной архитектуре, я сразу представлял один мощный компьютер или их ферму (сервер/ы) и множество других компьютеров попроще, клиентов. Причем связь всегда подразумевалась через сетевые интерфейсы (чтоугодно-over-IP). В этой книге же представлена историческая перспектива  средств взаимодействия процессов, и соответственно сервер определяется как процесс, предоставляющий некие сервисы (вычисляющий, предоставляющий данные по запросу извне). Такое определение или, скорее, описание, кажется мне более общим и корректным.

воскресенье, 1 сентября 2013 г.

Verification of your TeamViewer version failed

English version here.
Недавно попросили разобраться с утилитой Teamviewer, внезапно начавшей вываливаться с указанной в заголовке ошибкой. В качестве операционной системы выступала Windows XP. Как выяснилось, бинарник подписан ЭЦП, соответственно для прохождения проверки нужны :
1) рабочая крипто-инфраструктура.
2) загруженные корневые сертификаты.

Пункт 1) описан здесь http://support.microsoft.com/kb/958045/en-us, там же предложено решение (выполнить в консоли):

regsvr32 Softpub.dll /s
regsvr32 Wintrust.dll /s
regsvr32 Initpki.dll /s
regsvr32 Mssip32.dll /s


Пункт 2) заключается в установке корневых сертификатов отсюда: http://www.verisign.com/support/roots.zip (почитать: https://www.symantec.com/page.jsp?id=roots)

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

понедельник, 15 июля 2013 г.

о документировании сети

Задумался недавно о различных вариантах ведения документации на сеть, точнее о журнале адресации и различных (L3,L3 и т.д.) схемах сети.

Есть уже ощущение, что в 21 веке как-то грустно вносить руками префикс в excel-таблицу или дорисовывать новый линк в Visio, отдельно на L2-карте, отдельно на L3-карте. С другой стороны, многие автоматизированные решения предполагают использование CLI рабочего оборудования роботом с целью выяснения топологии. В таком варианте вполне вероятна ситуация, когда в результате ошибки робот начнет генерировать тяжелые для процессора запросы с высокой частотой, что приведет к высокой утилизации процессора и последующим неприятным событиям. Конечно, в некоторых устройствах некторых вендоров management plane и control plane независимы, но в общем случае не хотелось бы иметь такие риски. С другой стороны, в лучших домах Европы уже, как правило, реализовано архивирование и отслеживание версий конфигураций, так почему бы просто не парсить конфиги? Конечно, сначала необходимо задать базовую структуру сети (роли устройств и их связи), но затем добавление нового L3-линка, например, элементарно отследить по изменению конфигов. В случае включенных L2-discovery протоколов (CDP, LLDP) доступ к их данных можно [попытаться] получить через SNMP. В идеале из полученных данных можно собрать граф и визуализировать его стильным-молодежным js-фреймворком. Такие мысли.

TL;DR: пускать кого попало в cli неок, безопаснее парсить конфиги.

среда, 17 апреля 2013 г.

уна палабра нуэва

Недавно вычитал новое слово - "сормировать", в смысле направлять трафик на оборудование СОРМ-2. Занятно.

понедельник, 25 марта 2013 г.

суббота, 23 марта 2013 г.

mikov active-active HA & graceful service degradation

Дощелкался.
Есть у меня нож автоматический, Mikov, чешский. Вот такой (фото из интернета).

В сложенном состоянии клинок спрятан внутри рукояти, и при нажатии рычажка выбрасывается наружу пружиной. Точнее пружинами, их там две одинаковых. И вот недавно одна из них лопнула, и теперь нож иногда недораскрывается. Раньше их делали с одной пружиной, и в те времена в такой ситации надо было ждать новую. По мне, так вполне наглядный пример active-active HA (пружины работают одновременно) и graceful degradation (при поломке одной пружины в целом функциональность сохраняется). Занятно, как одни и те же принципы применимы в совершенно разных, казалось бы, областях.

суббота, 16 марта 2013 г.

load sharing vs load balancing

Хотелось бы уточнить некоторые нюансы терминологии.

Мне представляется неверным использование термина 'load balancing' (балансировка нагрузки) в контексте наличия нескольких путей перенаправления (форвардинга) трафика между его источником и пунктом назначения. В частности, при использовании агрегации физических портов в один логический (bonding в linux, teaming в windows, trunking у HP) или при наличии нескольких L3-маршрутов (equal cost multipath). Само слово 'балансировка' подразумевает, по моему мнению, динамическое изменение одного параметра (next-hop или выходной интерфейс) в зависимости от некоей метрики нагрузки. Подобным образом работают решения вроде F5 LTM, ACE и прочая. Например, если отклик одного из множества серверов или количество соединений на нем меньше, чем у остальных, следующий запрос будет направлен на него. В случае агрегации портов и l3-ecmp выбор пути, по которому будет направлен пакет, происходит, как правило, при помощи подсчета хэша от неких полей пакета. В некоторых случаях возможна, к примеру, полная утилизация одного из линков-членов агрегированного линка и низкая утилизация других.

Поэтому в этих контекстах уместнее говорить именно о 'разделении' нагрузки, load sharing.

примеро

Лень и желание "ничего не делать и чтобы все было" склонили меня к регистрации здесь вместо поднятия отдельного бложика на нгинкс+питон+скулайт. Вероятно, я буду здесь писать что-то про компьютерные сети. Вероятно, кому-то это поможет или покажется интересным.