Поставили патч на продукте ...
понедельник, 30 января 2017 г.
среда, 28 октября 2015 г.
Новый танк
Добрались до нового процессора от Oracle - M7
System Configuration: Oracle Corporation sun4v SPARC T7
================================ Virtual CPUs ================================
CPU ID Frequency Implementation Status
------ --------- ---------------------- -------
0 4133 MHz SPARC-M7 on-line
1 4133 MHz SPARC-M7 on-line
2 4133 MHz SPARC-M7 on-line
3 4133 MHz SPARC-M7 on-line
OpenSSL speed T7
hmac(md5) for 3s on 8192 size blocks: 490246
blowfish cbc for 3s on 8192 size blocks: 43357
4096 bit public rsa's for 10s: 42646
OpenSSL speed T5
hmac(md5) for 3s on 8192 size blocks: 382719
blowfish cbc for 3s on 8192 size blocks: 34591
4096 bit public rsa's for 10s: 29911
Реальная база работает в 2 раза быстрее
System Configuration: Oracle Corporation sun4v SPARC T7
================================ Virtual CPUs ================================
CPU ID Frequency Implementation Status
------ --------- ---------------------- -------
0 4133 MHz SPARC-M7 on-line
1 4133 MHz SPARC-M7 on-line
2 4133 MHz SPARC-M7 on-line
3 4133 MHz SPARC-M7 on-line
OpenSSL speed T7
hmac(md5) for 3s on 8192 size blocks: 490246
blowfish cbc for 3s on 8192 size blocks: 43357
4096 bit public rsa's for 10s: 42646
OpenSSL speed T5
hmac(md5) for 3s on 8192 size blocks: 382719
blowfish cbc for 3s on 8192 size blocks: 34591
4096 bit public rsa's for 10s: 29911
Реальная база работает в 2 раза быстрее
понедельник, 16 марта 2015 г.
О пользе статистики
Почему-то стала тормозить абонплата , расчет которой идет ночью
Вместо положенных 3 часов - сначала 5 , затем 7
Беглый взгляд на IO сразу обозначил причину
При этом svc_time не вырос , transfer вырос но не так сильно .
Причину нашли быстро - неудачно поправленный запрос .
пятница, 6 июня 2014 г.
Практическое применение Ethernet fabric ч.3
Ethernet Fabric - практическое применение ч. 3
Как я уже говорил , для технологии Oracle standby очень важно обеспечить отказоустойчивую и низколатентную связь между серверами . Казалось бы , что проще - взять отдельные коммутаторы типа Циски и соединить с их помощью Primary и Standby
Примерно так :
Все это будет замечательно работать , пока кто-нибудь случайно не дернет оптику или повредит ее.
Примечание - Primary и Standby лучше размещать на разных площадках , пусть и недалеко друг от друга . Изображен именно такой вариант .
Для борьбы с повреждениями линий надо проложить их несколько
Сделали транк , все хорошо .
Но - у нас остается одна линия от сервера до коммутатора
Ставим двухпортовую сетевую карточку , поднимаем IPMP
Все хорошо , все замечательно работает , все довольны .
Длится сие счастье ровно до того момента , когда связь между площадками все же падает .
Причина проста - сетевой коммутатор на каждой площадке является критичной точкой отказа - потому что он один
Какой бы он не был надежный ,самого суперименитого вендора , с дважды задублированными блоками питания и прочими элементами внутри - он обязательно выйдет из строя . Или перезагрузится . Это закон жизни , к сожалению проверенный и неоднократно .
Стандартный путь избежания такой ситуации - дублирование критичных узлов . Метод древний , но нечасто применяемый из-за экономии . Но если Вам нужна действительно отказоустойчивая сеть - это необходимо .
То есть на одной площадке ставится два коммутатора. К каждому коммутатору идет отдельный линк от сервера - полное дублирование
Схема с 4 коммутаторами должна по идее быть вот такой
Вроде бы все хорошо , при выходе из строя коммутатора 1 или 2 IPMP сработает и пакеты будут ходить через 3 и 4 .
Опять таки - все хорошо , все замечательно работает и т.д.
"Но есть нюанс" (с)
Однако представим , что вышел из строя не к.1 , а линия между 1 и 2
С точки зрения сервера - все хорошо , линк между сервером и к.1 не упал - то есть переключения IPMP НЕ происходит .
Можно конечно отказаться от link-base mode в пользу probe-based IPMP. Однако при это встает еще более сложный вопрос - какова надежность probe-base обьекта и как ее обеспечить ?
Самое простое решение - соединить коммутаторы 1 и 3
Схема замечтаельная , но вот только ни один обычный Ethernet коммутатор так работат не сможет - кольцо . В лучшем случае после задержки STP поотключает к черту все "лишние " пути .
Решение - Ethernet Fabric
Для нее такая схема является абсолютно штатной .
Для параноидального поднятия отказоустойчивости можно сделать Full mesh , соединив 1--> 3 , 2-->4
В случае выхода одного свича или одного транка между площадками - все работает штатно .
Примерно такая схема реализована в нашем датацентре , посмотрим теперь как это работает .
Сетевой траффик идет по кратчайшему пути - по линку 1-4 .
В какой-то момент этот линк рвется .
На картинке ниже - сетевой поток по портам коммутатора 1
порт 20 - это линк 1-4
порт 17 и 18 - это линки 1-2 и 1-3
Очень хорошо видно , как поток из порта 20 распределяется по портам 17 и 18 .
Скорость переключения путей в фабрике очень высокая - на уровне пингов задержек не заметно .
После восстановления линка трафик моментально возвращается на кратчайший путь
Вывод - Ethernet Fabric действительно позволяет построить очень надежную сеть .
Как я уже говорил , для технологии Oracle standby очень важно обеспечить отказоустойчивую и низколатентную связь между серверами . Казалось бы , что проще - взять отдельные коммутаторы типа Циски и соединить с их помощью Primary и Standby
Примерно так :
Примечание - Primary и Standby лучше размещать на разных площадках , пусть и недалеко друг от друга . Изображен именно такой вариант .
Для борьбы с повреждениями линий надо проложить их несколько
Но - у нас остается одна линия от сервера до коммутатора
Ставим двухпортовую сетевую карточку , поднимаем IPMP
Длится сие счастье ровно до того момента , когда связь между площадками все же падает .
Причина проста - сетевой коммутатор на каждой площадке является критичной точкой отказа - потому что он один
Какой бы он не был надежный ,самого суперименитого вендора , с дважды задублированными блоками питания и прочими элементами внутри - он обязательно выйдет из строя . Или перезагрузится . Это закон жизни , к сожалению проверенный и неоднократно .
Стандартный путь избежания такой ситуации - дублирование критичных узлов . Метод древний , но нечасто применяемый из-за экономии . Но если Вам нужна действительно отказоустойчивая сеть - это необходимо .
То есть на одной площадке ставится два коммутатора. К каждому коммутатору идет отдельный линк от сервера - полное дублирование
Схема с 4 коммутаторами должна по идее быть вот такой
Вроде бы все хорошо , при выходе из строя коммутатора 1 или 2 IPMP сработает и пакеты будут ходить через 3 и 4 .
Опять таки - все хорошо , все замечательно работает и т.д.
"Но есть нюанс" (с)
Однако представим , что вышел из строя не к.1 , а линия между 1 и 2
С точки зрения сервера - все хорошо , линк между сервером и к.1 не упал - то есть переключения IPMP НЕ происходит .
Можно конечно отказаться от link-base mode в пользу probe-based IPMP. Однако при это встает еще более сложный вопрос - какова надежность probe-base обьекта и как ее обеспечить ?
Самое простое решение - соединить коммутаторы 1 и 3
Схема замечтаельная , но вот только ни один обычный Ethernet коммутатор так работат не сможет - кольцо . В лучшем случае после задержки STP поотключает к черту все "лишние " пути .
Решение - Ethernet Fabric
Для нее такая схема является абсолютно штатной .
Для параноидального поднятия отказоустойчивости можно сделать Full mesh , соединив 1--> 3 , 2-->4
В случае выхода одного свича или одного транка между площадками - все работает штатно .
Примерно такая схема реализована в нашем датацентре , посмотрим теперь как это работает .
В какой-то момент этот линк рвется .
На картинке ниже - сетевой поток по портам коммутатора 1
порт 20 - это линк 1-4
порт 17 и 18 - это линки 1-2 и 1-3
Очень хорошо видно , как поток из порта 20 распределяется по портам 17 и 18 .
Скорость переключения путей в фабрике очень высокая - на уровне пингов задержек не заметно .
После восстановления линка трафик моментально возвращается на кратчайший путь
Вывод - Ethernet Fabric действительно позволяет построить очень надежную сеть .
четверг, 5 июня 2014 г.
Ethernet Fabric от Brocade ч. 2
Сетевой триллер
Повторюсь , основное для чего создавался классический ethernet - передать пакет от MAC1 ---> MAC2 , кроме MAC -нет ничего .
То есть нехватает чего ?
Правильно -возможности маршрутизировать ethernet пакеты ,L2 routing
Это стало очевидно довольно давно , и IETF разработал новый стандарт своеобразного названия
“The TRILL WG will design a solution for shortest-path frame routing in multi-hop IEEE 802.1-compliant Ethernet networks with arbitrary topologies, using an existing link-state routing protocol technology.”
The Brocade Ethernet fabric uses Transparent Interconnection of Lots of Links (TRILL) protocol, designed for the sole purpose of scaling Ethernet networks by allowing a set of devices, called routing bridges (RBridges), to connect with each other.
Основные цели протокола :
•
Uses shortest path routing
•
Works at Layer 2
•
Supports multi-hopping environments
•
Works with an arbitrary topology
•
Uses an existing link-state routing protocol
•
Remains compatible with IEEE 802.1 Ethernet networks that use STP
По-простому протокол назвали TRILL , суть его - ethrnet пакет запихивается внутрь TRILL пакета , при это сам TRILL имеет стандартный формат и совместим с обычным оборудованием .
Инкапсуляция , одним словом .
Свичи , работающие с таким протоколом , назвали routing bridges (RBridges)
Формат пакета -
Посмотрим теперь как путешествуют эти пакеты
Возникает вопрос - а откуда RB1 знает , куда посылать TRILL пакет - RB4 или RB5 ?
Для решения этого ,насколько я понимаю ,Brocade применила свой протокол SPF , успешно реализованный в SAN и слегка модифицированный . Все свичи обмениваются информацией , и каждый вычисляет самый короткий путь до пункта назначения . Если путей несколько и они одинаковы - пакеты передаются по обеим .
Обмен информацией между свичами и есть формирование Ethernet Fabric - так назвали эту технологию Brocade .
В оригинале -
The Brocade VCS Fabric Ethernet fabric is defined as a group of switches that exchange information between each other to implement distributed intelligence.
TRILL enables Layer 2 networks to behave like routed Layer 3/IP networks.
Brocade VCS Fabric technology leverages proven FC Fabric protocols to build a TRILL fabric. The main functions of the fabric formation protocols are to:
•
Assign the Brocade VCS Fabric-wide unique RBridge IDs (Domain ID Assignment)
•
Create the network topology database using link state routing protocol (Fabric Shortest Path First, or FSPF). FSPF calculates the shortest path routes to a destination RBridge.
•
Distribute fabric multicast traffic.
Таким образом , Ethernet fabric - это принципиально новая сетевая технология , призванная ликвидировать недостатки традиционного Ethernet .
Позволяет построить сеть с минимальными и гарантированными задержками в передаче , не боится петель и поддерживает несколько путей передачи пакетов
В итоге получается например такая топология сети
Brocade выпустило линейку устройств на основе данной технологии
- семейство VDX 67XX , это обычные 2 юнитовые свичи и большие шасси VDX 8770 .
Brocade также выпускает линейку "обычных" Ethernet свичей и маршрутизаторов разного уровня - Brocade BigIron RX Series,Brocade FastIron SX Series,Brocade TurboIron 24X Switch ,Brocade MLX
среда, 4 июня 2014 г.
Ethernet Fabric от Brocade ч. 1
Ethernet Fabric от Brocade ч. 1
Решил рассказать про успешный опыт использования этой технологии , тем более что складывается впечатление , что в России она совсем не распространена
Для начала - для чего это надо
Начинать придется издалека - с основ , которые сейчас основательно забыты под ворохом навершанных плюшек и костылей .
Небольшой ликбез в общем
Сеть Ethernet изначально создавалась как сеть с негарантированной достакой пакетов .То есть
а. пакеты могут теряться
б. время доставки пакетов в общем случае может быть любым
Пункт а. решается переповторами в вышестоящих протоколах
Пункт б. для большинства приложений не особо важен , где важен решался тупо увеличением скорости сети 10Mb->100Mb->1Gb-10Gb
Все это общеизвестно , однако отметим еще одно важное обстоятельство - Ethernet создавался как протокол доступа точка-точка (MAC-MAC) в одном разделяемом множеством точек сегменте (изначально коаксиале). Это означает что Ethernet подразумевает один путь между точками и не может работать по нескольким сегментам . Это означает также , что одна точка посылает свой пакет второй не зная где она собственно находится .
Усложним схему - добавим Ethernet swith L2
В этом случае свич конечно знает , на каких портах находятся MAC адреса и пересылают пакеты по этой таблице .
Усложним схему до более реальной - свичей несколько .
Если свич не знает некий MAC адрес то он отправляется другому - может требуемое устройство там .
Проблема в том , что свичи не могут знать , отправляли ли они этот пакет перед этим . В результате возникает хорошо известная проблема зацикливания пакетов в случае нескольких свичей , если они не дай бог соединились кольцом .
Пакеты будут бесконечно бегать по треугольнику , свичи перегрузятся и сеть перестанет работать .
Для решения такой проблемы был придуман костыль STP , блокирующий порты .
Казалось , бы все замечательно .
Но - время срабатывания STP не моментальное , и сеть на какое-то время становится полностью . Само собой , невозможность передавать Ethernet пакеты по нескольким путям ограничивает скорость и понижает надежность .
Все дублирующие линки будут положены . ( картинки сперты из материалов Brocade)
Со всеми этими недостатками особо не парились , пока Ethernet сети использовались для офиса и Интернета и пока не появился 10g в локальных сетях .
Тут же возник соблазн использовать 10g для замены FC SAN и появилась технология FCOE .
Очеь быстро выяснилось , что на обычном Ethernet более-менее серьезный дисковый ввод-вывод работает плохо .
Причины очевидны - даже при просмотре потокового видео задержки в 3-5 мс особо не заметны , а вот для нагруженного сервера это заметно очень сильно .Особенно если эти задержки хаотичны и происходят на записи редологов.
64 bytes from 10.0.2.120 : icmp_seq=1265. time=0.603 ms
64 bytes from 10.0.2.120 : icmp_seq=1266. time=0.529 ms
64 bytes from 10.0.2.120 : icmp_seq=1267. time=4.103 ms
64 bytes from 10.0.2.120 : icmp_seq=1268. time=0.450 ms
64 bytes from 10.0.2.120 : icmp_seq=1269. time=0.573 ms
Более того , некоторые решения/приложения требуют минимальных задержек просто при передаче данных , без всякого IO .
Одним из таких решений является Oracle Standby in Max. availability mode .
Standby (очень грубо ) является зеркалом оракловой базы , изменения
передаются то сети . В случае задержек передачи в указанном режиме
Primary начинает автоматически подтормаживать , чтобы сохранить синхронность . Само собой это крайне негативно сказывается на работе приложений , завязанных на эту базу .
С указанной ситуаций , к сожалению , пришлось столкнуться .
Primary и Standby соединялись локалькной сетью с скоростью 1Gb
Такой скорости более чем достаточно для передачи , но периодические увеличения задержек крайне негативно влияли на работу
На рисунке - характерный пик ожиданий на базе
Отмечу , что локальная сеть собрана совершенно правильно , мощности Cisco хватает с избытком .
Но задержки , возникающие в обычной ethernet - неизбежны .
Решил рассказать про успешный опыт использования этой технологии , тем более что складывается впечатление , что в России она совсем не распространена
Для начала - для чего это надо
Начинать придется издалека - с основ , которые сейчас основательно забыты под ворохом навершанных плюшек и костылей .
Небольшой ликбез в общем
Сеть Ethernet изначально создавалась как сеть с негарантированной достакой пакетов .То есть
а. пакеты могут теряться
б. время доставки пакетов в общем случае может быть любым
Пункт а. решается переповторами в вышестоящих протоколах
Пункт б. для большинства приложений не особо важен , где важен решался тупо увеличением скорости сети 10Mb->100Mb->1Gb-10Gb
Все это общеизвестно , однако отметим еще одно важное обстоятельство - Ethernet создавался как протокол доступа точка-точка (MAC-MAC) в одном разделяемом множеством точек сегменте (изначально коаксиале). Это означает что Ethernet подразумевает один путь между точками и не может работать по нескольким сегментам . Это означает также , что одна точка посылает свой пакет второй не зная где она собственно находится .
В этом случае свич конечно знает , на каких портах находятся MAC адреса и пересылают пакеты по этой таблице .
Усложним схему до более реальной - свичей несколько .
Если свич не знает некий MAC адрес то он отправляется другому - может требуемое устройство там .
Проблема в том , что свичи не могут знать , отправляли ли они этот пакет перед этим . В результате возникает хорошо известная проблема зацикливания пакетов в случае нескольких свичей , если они не дай бог соединились кольцом .
Пакеты будут бесконечно бегать по треугольнику , свичи перегрузятся и сеть перестанет работать .
Для решения такой проблемы был придуман костыль STP , блокирующий порты .
Но - время срабатывания STP не моментальное , и сеть на какое-то время становится полностью . Само собой , невозможность передавать Ethernet пакеты по нескольким путям ограничивает скорость и понижает надежность .
Со всеми этими недостатками особо не парились , пока Ethernet сети использовались для офиса и Интернета и пока не появился 10g в локальных сетях .
Тут же возник соблазн использовать 10g для замены FC SAN и появилась технология FCOE .
Очеь быстро выяснилось , что на обычном Ethernet более-менее серьезный дисковый ввод-вывод работает плохо .
Причины очевидны - даже при просмотре потокового видео задержки в 3-5 мс особо не заметны , а вот для нагруженного сервера это заметно очень сильно .Особенно если эти задержки хаотичны и происходят на записи редологов.
64 bytes from 10.0.2.120 : icmp_seq=1265. time=0.603 ms
64 bytes from 10.0.2.120 : icmp_seq=1266. time=0.529 ms
64 bytes from 10.0.2.120 : icmp_seq=1267. time=4.103 ms
64 bytes from 10.0.2.120 : icmp_seq=1268. time=0.450 ms
64 bytes from 10.0.2.120 : icmp_seq=1269. time=0.573 ms
Более того , некоторые решения/приложения требуют минимальных задержек просто при передаче данных , без всякого IO .
Одним из таких решений является Oracle Standby in Max. availability mode .
Standby (очень грубо ) является зеркалом оракловой базы , изменения
передаются то сети . В случае задержек передачи в указанном режиме
Primary начинает автоматически подтормаживать , чтобы сохранить синхронность . Само собой это крайне негативно сказывается на работе приложений , завязанных на эту базу .
С указанной ситуаций , к сожалению , пришлось столкнуться .
Primary и Standby соединялись локалькной сетью с скоростью 1Gb
Такой скорости более чем достаточно для передачи , но периодические увеличения задержек крайне негативно влияли на работу
На рисунке - характерный пик ожиданий на базе
Но задержки , возникающие в обычной ethernet - неизбежны .
пятница, 13 декабря 2013 г.
Про сжатие трафика
Как я уже упоминал , у нас есть удаленный DRC Oracle standby , куда накатываются изменения локальной базы . Недавно решили развернуть еще одну базу в DRC , гораздо большего обьема .
Сразу было понятно , что передать всю базу ХХ терабайт стандартным путем нереально , время только передачи получалось более месяца . В таком варианте накатывать изменения было уже бессмысленно - переданные данные уже устарели бы.
Отмечу , что к DRC проложены 2 канала - широкий основной и узкий резервный .
Возникла мысль передавать данные по двум каналам одновременно , чтобы использовать свободную полосу основного канала + резервный .
Гугление выявило два варианта - SCTP и Multipath TCP
Тут же выяснилось , что несмотря на описания , SCTP не умеет передавать данные одновременно. Вроде есть патч , но все это в состоянии глубокой альфы .
С MTCP оказалось интереснее . Пачти под дебиан и шапку в наличии и вроде как рабочие . Поставили , начали пробовать .
Действительно , трафик идет по обоим каналам и собирается в конечной точке . Вот только скорость передачи по двум каналам получается меньше чем по одному узкому ..... Короче , с производительностью беда .
Поскольку с параллельной передачей вышел облом , самым разумным показалось сжимать трафик на лету дабы минимизировать обьем передаваемых данных .
Неспешное гугление показало , что продуктов со сжатием трафика немало , но почти все привязаны к протоколу . В 90% случаев - HTTP + RDP и тому подобное . Для наших целей это не подходит совершенно , нужен компрессор IP траффика . Ближе всего в этому софтовые VPN с опцией сжатия .
В итоге оказалось три кандидата -
OpenVPN
tincd
vtun
Последний ранее использовался , но результаты были не очень и сам продукт давно заброшен .
Начали с свежего tincd . Скачал , поставил, настроил , сталь гонять трафик . Результат оказался крайне неутешительным - при потоке более 100 Мбит клиент и сервер сразу стали жрать 100% CPU
Причем даже без сжатия !
С OpenVPN оказалось интереснее . В принципе , он позволял передавать поток с большой скоростью + сжимать его . Вот только стабильных результатов мы так и не достигли . По непоняитным причинам передача файла сегодня проходила со скоростью 270Мбит , а завтра - 120 .
Многочисленные попытки разобраться ничего не дали .
Пришлось вернуться к vtun , он по крайней мере работал стабильно . После небольшого числа тестов удалось найти рабочую конфигурацию и начать передачу данных в DRC .
Примерный порядок получившейся скорости передачи и сжатия виден на картинке -
Зеленый график - это то что прошло по каналу , синий - реальный .
В итоге - передача и накат изменений заняли менее трех недель .
Сразу было понятно , что передать всю базу ХХ терабайт стандартным путем нереально , время только передачи получалось более месяца . В таком варианте накатывать изменения было уже бессмысленно - переданные данные уже устарели бы.
Отмечу , что к DRC проложены 2 канала - широкий основной и узкий резервный .
Возникла мысль передавать данные по двум каналам одновременно , чтобы использовать свободную полосу основного канала + резервный .
Гугление выявило два варианта - SCTP и Multipath TCP
Тут же выяснилось , что несмотря на описания , SCTP не умеет передавать данные одновременно. Вроде есть патч , но все это в состоянии глубокой альфы .
С MTCP оказалось интереснее . Пачти под дебиан и шапку в наличии и вроде как рабочие . Поставили , начали пробовать .
Действительно , трафик идет по обоим каналам и собирается в конечной точке . Вот только скорость передачи по двум каналам получается меньше чем по одному узкому ..... Короче , с производительностью беда .
Поскольку с параллельной передачей вышел облом , самым разумным показалось сжимать трафик на лету дабы минимизировать обьем передаваемых данных .
Неспешное гугление показало , что продуктов со сжатием трафика немало , но почти все привязаны к протоколу . В 90% случаев - HTTP + RDP и тому подобное . Для наших целей это не подходит совершенно , нужен компрессор IP траффика . Ближе всего в этому софтовые VPN с опцией сжатия .
В итоге оказалось три кандидата -
OpenVPN
tincd
vtun
Последний ранее использовался , но результаты были не очень и сам продукт давно заброшен .
Начали с свежего tincd . Скачал , поставил, настроил , сталь гонять трафик . Результат оказался крайне неутешительным - при потоке более 100 Мбит клиент и сервер сразу стали жрать 100% CPU
Причем даже без сжатия !
С OpenVPN оказалось интереснее . В принципе , он позволял передавать поток с большой скоростью + сжимать его . Вот только стабильных результатов мы так и не достигли . По непоняитным причинам передача файла сегодня проходила со скоростью 270Мбит , а завтра - 120 .
Многочисленные попытки разобраться ничего не дали .
Пришлось вернуться к vtun , он по крайней мере работал стабильно . После небольшого числа тестов удалось найти рабочую конфигурацию и начать передачу данных в DRC .
Примерный порядок получившейся скорости передачи и сжатия виден на картинке -
Зеленый график - это то что прошло по каналу , синий - реальный .
В итоге - передача и накат изменений заняли менее трех недель .
Подписаться на:
Сообщения (Atom)