пятница, 30 декабря 2011 г.

Oracle и DNS

Даже не знаю, с чего начать статью. :)

Дело, собственно, в следующем. За последние полгода я несколько раз сталкивался с ситуацией, когда в определенных обстоятельствах оракловая база не стартует. При полной физической исправности. Либо к совершенно исправной работающией БД невозможно приконнектиться из сервера приложений.

Вскрытие показало, что больной умер в результате вскрытия ;)

Итак, в чем суть проблемы?

Суть проблемы - во взаимоотношениях Oracle RDBMS, Oracle Net и DNS.

Во-первых, о проблеме запуска.

В БД Oracle хардкодом вбито разрешение собственного имени сервера при старте базы, а точнее, при старте процесса SMON. На некоторых платформах (например, AIX5L), у которых при настройке разрешения имен первым не используются в обязательном порядке файлы hosts, а только затем DNS, в случае недоступности сервера (серверов) имен база отказывается стартовать.

Кстати, на Солярисе такие случаи мне лично незнакомы, поскольку в файле /etc/nsswitch.dns всегда первым идет разрешение посредством files:


# You must also set up the /etc/resolv.conf file for DNS name
# server lookup. See resolv.conf(4).
hosts: files dns


Соответственно, такой проблемы не возникает. Но так резолвер по умолчанию настроен не на всех платформах.

А вот данное поведение СУБД совсем не хорошо задокументировано. Во всяком случае, большими красными буквами это в руководствах не выделено и с разбегу не находится. Ровно до момента, когда вы с этим сталкиваетесь и лезете в службу технической поддержки с кодом ошибки. Причем в ноте саппорта сказано лишь "Проверьте /etc/resolv.conf".

На платформе AIX симптом недоступности DNS подтверждается затяжным коннектом к серверу по SSH, в котором по умолчанию также включено UseDNS yes.

Вторая проблема - с отсутствием подключения серверов приложений к работающей на момент недоступности DNS-серверов базе данных - менее очевидна. 

Для клиентов база данных выглядит полностью недоступной. И они начинают гневно доставать DBA. ;)

Диагностируется данная проблема посредством файла sqlnet.log, фиксирующим таймауты ns при установлении клиентских соединений.

Самый главный вопрос - что делать?

Первое и самое правильное решение: иметь в /etc/resolv.conf не менее двух внутренних (по отношению к локаальной сети) и полностью контролируемых DNS, один из которых должен быть всегда доступным - в частности, доступным по сети (обратите внимание, если сервер работает, но пакеты теряются - эффект будет примерно таким же: периодически пропадающие соединения с базой!).

Второе - сменить либо настройки резолвера сервера - на использование первым файла /etc/hosts и лишь после него - DNS, либо ОС сервера. ;)

Самое главное - кидаться проверять базу не нужно. Достаточно беглого взгляда на alert.log, чтобы убедиться, что с ней все нормально ну, или при проблемах старта - что происходит.

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

пятница, 23 декабря 2011 г.

Джинн и бутылка

Первое правило волшебника гласит:
Люди глупы. Люди глупы, и, если правдоподобно объяснить, почти все поверят во что угодно. Люди глупы и могут поверить лжи, оттого что хотят верить, будто это правда, или оттого что боятся знать правду. Головы людей полны всякими знаниями и верованиями, большинство из которых ложны, но все же люди в это верят. Люди глупы: они редко могут отличить правду от лжи, но не сомневаются, что способны на это. Тем легче их одурачить.

Первое правило волшебника, Т.Гудкайнд


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

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

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

Нет, это еще не клиническая идиотия. Хотя и производит  такое впечатление при более детальном рассмотрении.

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

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

Всего лишь три примера.
  1. Интернет. 
  2. Wi-Fi. 
  3. Социальные сети.
Вы хотите об этом поговорить?

Пожалуйста.

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

Никто и не думал закладывать ничего подобного рубильникам, дабы вырубать города и страны в случае чего. Чего? А никто не думал, чего может быть.

Ладно.

Джинна выпустили.

Всего через пяток лет интернет сначала наводнило порно в масштабах Всемирного Потопа. А фиг ли? Швабода же! Демократия! Анонимусы!

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

Начались поиски затычки.

"Товарищи! Потерпите еще год! Затычку уже ищут!"

При том, что фактически никаких тормозов в конструкцию этого, с позволения сказать, автомобиля изначально не было заложено by design.

Кстати, как вам лично понравится автомобиль для храбрецов без тормозов? М?

Но я отвлекся. 

Дальше - больше.

Внезапно выяснилось, что в отсутствие тормозов тормозить все-таки как-то надо, в некоторых отдельно взятых случаях или отдельно взятых странах.

Метод ста китайцев, построивших с этой целью пресловутый Голден ШитГолден Шилд, собссна, работает лишь в одной отдельно взятой стране. Где эти сто китайцев обитают. И то - фигово-фигово. Пакетик дырочку-то найдет. ШитТо бишь Шилд всегда проигрывает Сворду.

Ну ладно, хрен с вами. Пытаетесь контролировать, дабы джинн слишком уж не буйствовал - хрен с вами, пытайтесь. Но брехать-то так неуклюже зачем? "Ах-ох, мы ничего не фильтруем и не блокируем! Это они, супостаты, у них вот весь сайт работает, но вот эта отдельно взятая сцылочка, вредная для вашего душевного здоровья, она по техническим проблемам на стороне сервера недоступна, панимаишь! И это на сервере, выдерживающем 200 миллионов посетителей в день, да, верьте нам!"

Чувствуете, автомобильчик-то без тормозов by design! Тормоза изобрели трусы! Поэтому давайте тормозить во-он той веточкой, которую сорвали с придорожного растущего деревца.

Однако, я отвлекся.

Что? Нельзя было просчитать тогда, 15 лет назад, во что все выльется? Стоп, при чем тут Нострадамус? Плохо знакома природа людей? Любопытство, основной инстинкт, бесконечное желание обезьянок общаться? Не нужно быть Нострадамусом, чтобы знать об этом.

Ладно. Проехали.

С Wi-Fi вообще особый и милейший разговор. Удобная - в принципе! - технология оказалась мало того, что изначально дырявой, так еще и двойного назначения. А к тому моменту, когда выяснилось, что она преимущественно хороша для хаксоров, и начали шевелить мозжечками, говоря, что не хилтон бы лицензировать-контролировать-и всякое такое, поезд уже ушел. Опа! - проснулись, а кругом сплошные точки доступа! Ну-кося, конфискуй-ка столько девайсов из личной собственности у собственных граждан!

Гм. Совок догадывался пишмашинки и факсы с ксероксами контролировать, а современные умники не допетрили, чем обернется беспроводной доступ? Простите, чем-чем, вы говорите, вы думаете?

Социалки вообще песнь песен.

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

Что имеем теперь? Терабайты пиратского контента, детской порнографии, а, самое главное, рассадник погромов и революций!

Давайте теперь героически решать возникшие проблемы, да. Начнем требовать от IT-специалистов невозможного - автоматического анализа терабайт и терабайт контента на предмет экстремизма-порнографии-пиратского контента-нужное подчеркнуть.

Ничего, что искусственный интеллект остановился в развитии на состоянии 1965 год примерно? Ничего, что анализ такого эвереста дерьмаданных в реальном времени лежит за пределами законов сохранения и квантовых лимитов?

Что, не ждали? Что остальные хомо тоже, в общем-то, оборудованы головным мозгом и приспособят ножички не только хлебушек порезать, но и оппоненту кишочки выпустить?

Давайте теперь героически порешаем и эту возникшую проблему. Попробуем ее решением судов позакрывать и попугать анонимусов, делая пальчиками "козу" и приговаривая "Бу! Пачпорт покаж! Или его скан, тащемта!". История с Салманом Рушди (веселюсь) и его паспортом в Фейсбуке меня вообще позабавила, особенно в свете того, что я писал раньше.

(с иронией)

А уже есть и инет, и Wi-Fi, и Тор с Фринетом. Что, нашли 6 миллиардов дурочек, которые не найдут лазейку или целые ворота?

Вернемся к нашим барашкам.

Отсутствие хотя бы сколько-нибудь приличной дальновидности и хотя бы чего-то, отдаленно напоминающего воображение, у тех, кто призван, вообще говоря, быть тормозом и рулем, разочаровывает. Люди далеко не всегда знают в точности, что им будет лучше и насколько глубока та пропасть впереди. Примеры Фукусимы и многие другие, я думаю, в достаточной степени свежи.

Рулевые-то, вообще говоря, с завязанными глазами рулят. По большей части.

В IT всему вышесказанному, между нами, есть определение.

То, о чем я писал до сих пор, называется в IT "Реактивное администрирование".

В переводе на простой русский язык это звучит так - "Гром не грянет - мужик не перекрестится".

В профессии это считается плохим тоном, однако так живет 95% профессионалов и не жужжат, что называется. В общем-то, так 95% всех человеков живет.

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

Называется она "Проактивное администрирование".

Так же, простыми словами - "Видимость ноль, иду по приборам, однако через 15 копеек поворот налево".

(с иронией)

То, к чему оказался не склонен капитан Очевидность "Титаника".

Этот болван видел или, как минимум, догадывался, что впереди айсберг, однако далее было то, что всем прекрасно известно по одноименному рыдательному фильмецу Кэмерона.

Что, хорош критиковать? Пора предлагать?

А как же. Сейчас предложу. Собственно, уже предложил.

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

Эй, вы, там! Наверху!

Существует такой зверь, как аналитик! Нанимайте аналитиков, держите волосатые лапы на всех пульсах, до которых дотянетесь, просчитывайте ситуацию хотя бы лет на 10 вперед, а не просто пилите и откатывайте! Помните, что вы у руля, а не у корыта! И тогда - может быть! - вас пронесет от попадалова прямиком в айсберг через пару-тройку лет и не будет у вас прекрасных глазок тонущего Ди Каприо!

вторник, 20 декабря 2011 г.

ZFS: Не шутите с CoW!

Преамбула

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

В этой связи мне страшно нравится передача Discovery "Как это работает?" Пора такие видеоликбезы по IT выкладывать на YouTube, как мне представляется. Где популярно, языком телепередач, внушать IT-общественности, что законы физики вообще и законы сохранения в частности, в общем, в IT тоже действуют.

Жалоба CoWбоя

А теперь к делу.

Если вы внимательно следите за современными течениями в операционных системах, а конкретно - в области файловых систем, то наверняка знаете, что появилась устойчивая тенденция к созданию файловых систем, устроенных по принципу CoW - Copy-On-Write.

Что в переводе на простой русский язык означает - "Транзакционная семантика и запись измененных данных на новой место".

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

Приведу простой пример.

Допустим, у вас есть сторидж пул ZFS общим объемом 1 Тб. При этом он заполнен на 50%, и количество файлов на этих 50% (т.е. на 500 Гб) составляет, скажем, 10 млн штук. При этом приложение/приложения каждый час обновляет половину из них, что составляет в гигабайтах, допустим, 250 Гб.

Каждый раз, когда происходит транзакционное обновление 250 Гб, эти 250 Гб записываются в новое место.

Через 3 часа фактически свободное пространство на сторидж пуле заканчивается*.

Что произойдет после этого?

Солярис 10 в этой ситуации принудительно размонтирует пул. Последующее монтирование приведет к инициированию процедуры scrub, что, в случае 10 млн файлов, означает, что пул нельзя будет смонтировать до завершения полной проверки всех контрольных сумм приблизительно на протяжении суток-двух.

__________________________
* Я сознательно максимально упрощаю пример. Да, мне известно и о наличии лога намерений (intent log), который, если не вынесен на отдельные устройства, выделяется в пространстве пула, и о наличии включенного по умолчанию кэша L2, выделенного там же. С учетом их существования, при заданных в примере начальных условиях и при таком темпе изменений файловой системы все закончится еще быстрее. Примерно в три-четыре раза, в зависимости от разового объема записи и количества шпинделей пула. Опять-же, грубо. Желающие могут провести натурный эксперимент, в стиле "Разрушителей легенд" дабы лично убедиться в действии законов физики. :)
__________________________

Почему так?

По определению. Так написана файловая система.

Эффект, в общем, не нов. Некоторые неосиляторы концепций от IT еще пару лет назад лично убедились в существовании законов физики, когда, при 90% заполнении пула, обнаружили резкую деградацию производительности ZFS. Ну, еще бы! А куда, по-вашему, драйвер ФС должен писать копии измененных блоков в рамках транзакций? На Великий Небесный Сервер?

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

Что, не ждали?

Сюрприз! Концепции желательно не только курить, их желательно также понимать. Что требует уже наличия функционирующего головного мозга. ;)

Что делать и кто виноват?

Виноват, конечно, разработчик файловой системы, кто ж еще-то... Понапишут, блин, а тут потом сиди, разбирайся, кто дурак. Еще и исходники читай... Само должно работать! Искаропки!

А если серьезно?

Планировать СХД. С карандашом в руках. Оценивая не только потребную латентность, пропускную способность или IOPS, но и запас свободного пространства с учетом примерного планируемого объема дисковых транзакций и их темпа в единицу времени.

Данный недостаток подобных файловых систем является логическим продолжением их основных достоинств. Соответственно, нужно его учитывать

Как метко выразился один джентльмен (правда, немного по другому поводу), жесткий диск сейчас стоит дешевле лопаты дерьма. Кто мешает хотя бы 50% запас по дисковому пространству иметь? Ах, вы не ждали такого поведения файловой системы... Ну, что ж.  Ошибки в генах программно не исправляются.

Что делать, если все-таки влипли? Прохлопали ушами и пул отвалился?

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

Да, есть ломовое средство. Удалить в безопасном режиме /etc/zfs/zfs.cache, перезагрузиться в опасный режим, разрушить пул, создать заново, и восстановить данные - хотя бы частично - со снапшотов (разумеется, если вам хватило ума организовать процедуры резервного копирования. Что, как показывает практика, свойственно далеко не всем). Не допуская уже чрезмерного заполнения.

Не думаю, однако, что пользователей сервера устроит величина даунтайма и такое отношение к их данным.

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

Если пул, после завершения проверки, все-таки удалось импортировать, первым делом надо попытаться удалить лишние данные. Если это, опять-таки, удастся сделать.

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

Не надо жадничать.