май 302009
 

И то на тема „Oracle Clustering“ 🙂

Под постинга ми за ASM: Fast Mirror Resync се разрази малка, но много емоционална дискусия на тема Oracle CRS.

Там човекът, който се представя за владетел на подземното царство и не смее да застане с името си зад своите думи, ми направи показно как се води технологичен спор. Въпреки че някои неща от материята не са му много ясни (примерно не знае принципа на действие на VIP-а), успя, според думите на негов фен да ме завре в миша дупка по тема, която ми е много близко до сърцето. Това стана предимно с обиди към мен, към екипа, в който работя, към създателите на CRS и към самата технология, а не с конструктивните предложения, за които помолих. Но явно проработи, защото ето, аз се признавам за победен 🙂

И така, за всички, които искат да се научат да дебатират на технически теми, предлагам кратко помагало:

Относно екипа, в който работя: „някой не си е оптимизирал базата и не си е мръднал пръста за да прегледа какво прави Oracle и какви select-и се блъскат вътре“. Това е странно мнение за човек, който не е виждал кода, който се изпълнява, но е убеден, че го познава.

Относно технологиите, за кото спорим: „Oracle CRS (заместник на клъстерни решения от други vendor-и, complete FAIL)“. И още: „ASM-а е някакъв опит да се заместят storage вендор-те, което само по себе си е complete fail. Тук владетелят на подземното царство изрази много ясно и твърдо своята позиция. Още нещо: малоумието на CRS-a“ – да няма неясноти относно отношението на автора.

Малко мнения за някои от големите IT компании: „за справка на некадърниците виж HP, Microsoft, Oracle със тоя CRS-а „. От тук можем да разберем колко тежък е живота на Хадес, колко страда душата му (всъщност боговете имат ли души?) от факта, че е принуден да работи с продукти, създадени от некадърници.

Ето и едно по-конкретно оплакване от CRS: „Само олигофрен би halt-нал машина…“ и още „утре като се овапца нещо аз ще си троша тиквата с техните недомислици и меко казано малоумни решения на някои проблеми“. Тук отново авторът е болезнено експресивен, в желанието си да внуши на заблудения си противнуик в спора истината за обсъждания продукт.

А ето и оценката на анонимният дебатиращ за това от къде черпя информация: „На презентации и разни други fancy изпълнения, в които всичко се рисува в розови цветове съм се нагледал доста. Това е marketing crap, който един професионалист изобщо не го вълнува.“

Следват някои оценки за моят професионализъм и подготвеност по темата, върху която дебатираме: „Като за човек, който се изказва толкова компетентно по въпросите на клъстерните технологии, знаеш учудващо малко по тази тема…“. След един час Хадес установява, че аз не просто знам учудващо малко:„просто се дразня страшно много когато хора дават мнения по въпроси по които хал хабер си нямат…“. Ето и оценката за моят стил на дебатиране: „цитира разни slide-ве на разни хора, като папагал…“.

Тук Хадес обяснява отказа да застане зад своите думи: „Аз нямам кой знае какъв опит и репутация, рядко ми се налага да правя шарени презентации и да разтягам локуми. С това моето желание да споделям моите мизерни знания и наблюдения с пубнликата бяха поставени на мястото, което заслужават – в миша дупка, т.е. почти в подземното царство.

И за финал ето и едно мнение за разработчиците в Oracle: „някой дето го е пусал това няма акъл за 5 пари. С тази последна кама аз бях тотално разбит. Защото кой ще смее да защитата технология, разработена от човек с топлкова евтин ментален капацитет?

🙂

 Posted by at 10:17

ASM: disk_repair_time

 Общи  Коментарите са изключени за ASM: disk_repair_time
май 292009
 

В понеделник писах за приятната възможност на ASM за Fast Mirror Resync. Тогава забравих да спомена за един параметър (също нов в 11g), който е от съществено значение за тази функционалност: disk_repair_time.

Параметъра disk_repair_time указва колко време след отпадането на един диск имаме приятната възможност за Fast Mirror Resync.

Когато даден диск отпадне от дисковата си група, ASM започва да си води сметка кои от разположените върху него extents са променени в „отсъствие“ на диска. Тази информация се записва под формата на нещо като bitmap в ASM Header-а. На базата на този bitmap се прави и самият fast mirror resync когато се появи диска.

Обаче тази информация не може да се пази вечно. И вместо да се затормозяваме с някакъв синтаксис за триене на информация от тотално загинал диск, Oracle са го направили автоматично. След изтичането на определен период от време, информацията в този битмап се затрива; затрива се и всичката информация за съществуването на този диск (т.е. той се бори за загубен завинаги) – нещо като автоматичен drop disk. От това има две последствия:

– Ако успеем да възстановим диска, но това се случи след изтичането на периода, указан от disk_repair_time, той не се разпознава от системата като „свой“ и трябва да се добави като нов диск с add disk
– Когато изтече периода за disk_repair_time, поради drop-ването на диска започва ребалансиране на extent-и по наличните дискове. Това може да се възпрепятства ако се настори asm_power_limit=0.

Синтаксиса за сетване на параметъра disk_repair_time e:

SQL> ALTER DISKGROUP data SET ATTRIBUTE 'disk_repair_time' = '12h';

Diskgroup altered.

Проверка на текущата стойност се прави с:

select GROUP_NUMBER, VALUE from v$asm_attribute where name='disk_repair_time';

GROUP_NUMBER VALUE
------------ ------------------------------
           1 12h
           2 3.6h

Стойността по подразбиране, при стандартна ASM инсталация, е 3.6 часа. Тази стойност е взета от някаква статистика за средното време за отстраняване на хардуерен проблем с кабели, RAID контролери и т.н. Естествено, в България времето за доставка на един обикновен infinband кабел е поне 2 седмици (ако имаш късмет), така че това не важи за нас.

Според Oracle този параметър може да се сетне на произволно високa стойност. Това, обаче, е нож с две остриета: колкото повече време си дадем за оправяне на проблема (с последващ елементарен и бърз fast mirror resync), толкова по-дълго данните ни остават без mirror.

май 252009
 

Виждал съм много Oracle инсталации, които са „изсипани с лопатата“. Обичайната, ужасно стандартна картинка е следната: Дошъл, примерно, производител на софтуер и инсталирал своята система за billing/производство/HR или кой знае какво. И тази системка работи с Oracle Database. Обаче разработчиците не си дават много зор при инсталацията на Oracle софтуера и го дават с next-next-next… Фирмата, която си е купила софтуера, има един или двама сисадмини (най-много – може и да ги поддържа някой външен консултант). Този сисадмин разбира доста от Windows и или от Linux, от мрежи, от принтери и т.н. И няма как да бъде oracle гуру. И така се получава една… хм… не много оптимално работеща система.

Но това е само един от проблемите. Друг проблем е, че тая система работи с т.нар. base release – без никакви patchsets, да не говорим за отделни patch-ове. Което си е жива бомба за security, availability, performance, scalability и каквито още се сетите благини в една голяма комерсиална БД. Хайде, Oracle 11g излезе по-читав като Base release, но все пак…

Така описаната от мен ситуация е много тъжна, но голяма част от средният бизнес, че и част от „едрия“ за нашите мащаби, работи върху такива системи. И продължава да си работи, което е практическото доказателство, че може и да не са толкова страшни нещата.

Всичко кaзано до тук няма нищо общо с проблема, за който исках да пиша. Ама на тая тема паля от четвърт оборот. Защото съм ги сърбал такива попари…

Това, за което исках да пиша, е обратния случай – всички ние, които като добри хора си инсталираме patchsets, че даже и отделни interim patches и Critical Patch Update (CPU). Ние сърбаме друга попара:

OPatch, който е един от най-добрите patch tools, които съм виждал, е много внимателен и при инсталирането на кръпки винаги си прави backup на файловете, които мисли да подменя. Така ако стане нещо по време на наливането, винаги успява да върне предишното, (вероятно) стабилно състояние. Освен това запазва тези резервни копия и след като приключи, за да може ако след един ден (или месец) открием, че новия patch чупи нещо, да имаме тази възможност за стъпка назад. Честно казано не съм го тествал как се държи в по-заплетени случаи на слагане/махане на много зависими една от друга кръпки, но се надявам и да не опитвам.

Лошото е, че тези patch backups се натрупват в $ORACLE_HOME/.patch_storage и без проблем могат да станат повече от самата инсталация. И така може да се окаже, че без да знаем мястото на диска става все по-малко с всеки инсталиран interim patch и Critical Patch Update (CPU).

В Metalink note 550522.1 e описано по-подробно как в тази директория може да се натрупат няколко гигабайта „излишни“ файлове. И, по-важно, описано е как в последните версии на OPatch може да си върнем излишно заетото място без да извършваме безразборно клане триене. Тайната команда, която трябва да работи при всички по-съвременни версии на OPatch, е:

opatch util cleanup

С една такава команда аз получих следното неустоимо предложение:

Size of directory "/u01/product/11.1.0/db_1/.patch_storage" before cleanup is 2644331045 bytes.
Size of directory "/u01/product/11.1.0/db_1/.patch_storage" after cleanup is 191700734 bytes.

Това са си над 700 мегабайта, освободени без изобщо да се компрометира възможността на OPatch да деинсталира. Офертата наистина е уникална, защото още толкова успях да изстържа и от ASM home-а 🙂

 Posted by at 20:44
май 252009
 

Въведение:
Преди известно време Oracle обявиха пускането на пазара на Exadata Storage server. Това нещо представлява един HP DL180 G5 сървър наблъскан с 12 твърди диска. На него работи Oracle Linux 5.1 и малко допълнителен софтуер, който дава възможност на всеки Oracle Database 11.1.0.7 или по-нов да вижда тези 12 диска като локални през infiniband връзка. На практика това е нещо като shared storage, на който, обаче дисковете му се виждат като дискове, без никакви опити за RAID-ване. Всъщност има възможност от всеки физически диск да се направят няколко griddisks, като се прецизира физическото разпределение върху плочите.

Задачата:
Имам конфигурация с няколко Exadata cells и една RAC DB, чиито файлове са разположени върху тях. Искам да проверя какво ще се случи ако отпадне цял cell – дали ASM ще успее да поддържа работата на БД без абсолютно никакво прекъсване и колко време ще синхронизира дисковете като му ги върна. Дисковите групи са настроени с normal redundancy, т.е. всички данни са налични на 2 места (mirror).

Част 1:
Спирам без предупреждения един cell. В alert log-а на БД се появяват грозни съобщения:
Mon May 25 14:32:19 2009
Errors in file /ora11g/diag/rdbms/XXXX/XXXX1/trace/XXXX1_ckpt_31632.trc:
ORA-27603: Cell storage I/O error, I/O failed on disk o/10.0.1.153/DATA_CD_3_sagecell03 at offset 16826368 for data length 16384
WARNING: IO Failed. subsys:OSS dg:1, diskname:o/10.0.1.153/DATA_CD_3_sagecell03 disk:0x13.0xea55c0a4 au:4
iop:0x2af98b9dcaa0 bufp:0x2af98b757e00 offset(bytes):16826368 iosz:16384 operation:2(Write) synchronous:0
result: 4 osderr:0xc osderr1:0x0 pid:31632
OSS Subsystem error:12 (OSS_ERRCODE_NETWORKERR)
...
ORA-15080: synchronous I/O operation to a disk failed
WARNING: failed to write mirror side 2 of virtual extent 0 logical extent 1 of file 256 in group 1 on disk 19 allocation unit 4
WARNING: initiating offline of disk 19.3931488420 (DATA_CD_3_SAGECELL03) with mask 0x7e
NOTE: initiating MARK startup
Starting background process MARK
Mon May 25 14:32:20 2009
MARK started with pid=42, OS id=21872
NOTE: MARK has subscribed

Такива неща има за всичките дискове от този cell. В alertlog-а на ASM се появяват още грозни съобщения:

Mon May 25 14:32:19 2009
WARNING: initiating offline of disk 19.3931488420 (DATA_CD_3_SAGECELL03) with mask 0x7e
WARNING: kfk failed to open a disk[o/10.0.1.153/DATA_CD_2_sagecell03]

И тук такива съобщения има за всичките дискове от този cell.

Въпреки това БД продължава да си работи с пълна сила.

Част 2:
След около час и половина, в които БД работи без прекъсване, включих спреният cell. Както може да се очаква, ASM не може да се сети сам за тях – за него те са offline и той не ги търси. Закачих се с SQLPLUS към един от ASM instance-ите в клъстера:

SQL> select MOUNT_STATUS, NAME from v$asm_disk;

MOUNT_S NAME
------- ------------------------------
...
ONLINE  DATA_CD_7_SAGECELL04
OFFLINE DATA_CD_2_SAGECELL03
OFFLINE DATA_CD_5_SAGECELL03
OFFLINE DATA_CD_12_SAGECELL03
OFFLINE DATA_CD_8_SAGECELL03
OFFLINE DATA_CD_1_SAGECELL03
OFFLINE DATA_CD_10_SAGECELL03
OFFLINE DATA_CD_6_SAGECELL03
OFFLINE DATA_CD_3_SAGECELL03
OFFLINE DATA_CD_9_SAGECELL03
OFFLINE DATA_CD_4_SAGECELL03
OFFLINE DATA_CD_11_SAGECELL03
OFFLINE DATA_CD_7_SAGECELL03
ONLINE  DATA_CD_9_SAGECELL02
...

За да събудя възстановяването на данните от огледалните копия върху вече наличните дискове пуснах следната команда:

SQL> alter diskgroup DATA online disk DATA_CD_7_SAGECELL03,DATA_CD_11_SAGECELL03,DATA_CD_4_SAGECELL03,DATA_CD_9_SAGECELL03,DATA_CD_3_SAGECELL03,DATA_CD_6_SAGEGECELL03,DATA_CD_1_SAGECELL03,DATA_CD_8_SAGECELL03,DATA_CD_12_SAGECELL03,DATA_CD_5_SAGECELL03,DATA_CD_2_SAGECELL03;

Diskgroup altered.

SQL> select * from v$asm_operation;

GROUP_NUMBER OPERA STAT      POWER     ACTUAL      SOFAR   EST_WORK   EST_RATE EST_MINUTES ERROR_CODE
------------ ----- ---- ---------- ---------- ---------- ---------- ---------- ----------- --------------------------------------------
           1 ONLIN RUN           1          0          0          0          0           0

SQL> /

no rows selected

Както виждате, операцията е толкова бърза, че не можах да засека за колко време стана. Всъщност това е относително очакван резултат.

Защо става така:
Първо, при спирането на cell-а симулираме просто отпадане на диск. Е, всъщност на 12 диска. Това може да е породено от софтуерна или хардуерна грешка. Една от основните функции на ASM като high availability решение за дискове е да се справя в такава ситуация. И той наистина се справя – мърмори си в alertlog-а, но продължава да работи.

По-хубавото е бързото възстановяване на данните. Причина за това е новата в Oracle 11g функция Fast Mirror Resync. Когато един или няколко диска отпаднат без предупреждение, ASM започва да си записва кои extent-и са променени на огледалното копие. Така когато диска се върне, вместо да се rebuild-ва цялото огледало (12 диска по 450 GB са 5.4 терабайта!), се копират само промените. Това спестява много време и много IO. Естествено, това е полезно само ако се върне същият диск – примерно ако е имало проблемен кабел, повреден контролер, рестарт на cell и т.н.

Заключение:
И при отпадане на диск, и при връщането му, ASM работи много добре и точно според „рекламите“.

Още по въпроса
Тук не използвах параметрите ASM_POWER_LIMIT и новия за 11g DISK_REPAIR_TIME. Не знам дали и те работят както се очаква, но предвид видяното, нямам причини да се съмнявам.

 Posted by at 19:38

Изложба в Криптата

 Общи  Коментарите са изключени за Изложба в Криптата
май 212009
 

Вчера в Криптата под храм-паметника „Свети Александър Невски“ беше открита изложба, която ни показва интересни моменти от творчеството на тревненските иконописци през възраждането.

Това не е поредната изложба на икони. Показани са моменти от подготовката, понякога комбинирани в крайния резултат:

Тук има събрани много рисунки и копирки, които са ползвани от зoграфите при подготовката за рисуване на икони.


Ерминия


Рисунка. Разделена на сектори за по-правилно пренасяне върху дъска


Копирка. Изображението се пренася с набождане с карфици

Показани са и някои от инструментите, които са ползвали майсторите от възраждането.

Откриването беше посетено от много тревненци, живееши в София. Имаше екипи от Канал 1 и телевизия ББТ. Събитието беше уважено и от Н. Пр. Цунехару Такеда.

Изложбата ще остане в Криптата до 20 септември, когато ще се премести в Кърджали. Следващата година изложбата ще посети поне още 2 български града.

 Posted by at 19:30
май 192009
 

Супер яка търсачка на факти. Примери:

100 USD + 100 EURO: разбрах, че това са $235.91, чиято равностойност е моята местна валута е 339.66 лева. Автоматично се показа и графика за стойността на $235.91 в последната година и съответствие в 6 други валути.

What is the average weight of an indian elephant: разбрах, че средното тегло на elephas maximus е (2041 to 4990) kg.

Мoon rise today in sofia ми каза, че следващият изгрев на астрономическото тяло moon над областта Sofia,Sofija grad ще е на 3:17 am EEST | Wednesday, May 20, 2009. Това е след 11 hours 5 minutes 28 seconds, тогава ще остават 20 hours 43 minutes до полунощ и 2 hours 44 minutes до изгрева на слънцето (6:01 am). Има дори картинка как ще изглежда аналогов часовник и карта на небето.

Tryavna – население 13818 души, карта на България с точка в средата, час в местната часова зона, време: 26 deg C | relative humidity: 42% | wind: 1 m/s | partly cloudy

wikipedia – Разбрах от кого, кога и къде е регистриран домейна, статистика на посещенията и някаква неразбираема картинка.

next solar eclipse bulgaria: следващото слънчево затъмнение, което ще се види от България, е на 9:06 am EET | Friday, January 15, 2010 (0.6595 years from now). Има даже карта на земята с озображение от къде ще се вижда. И разни други неща.

Естествено, търсачката се справя само с най-глобални въпроси, но има огромен потенциал.

 Posted by at 16:35
май 052009
 

Не се наложи часовникът да ме събужда – вече бях станал, когато издрънча в 6:31. От толкова време не съм ходил „на баирче”, че нямах търпение да изляза от града.

Раницата, естествено, беше готова още от предния ден. Знаех, че, както винаги, съм взел много повече неща, от колкото ще ми потрябват. В крайна сметка тръгвам само за 3 дни, и то не на палатка, а на хижа. Но страшните прогнози за времето ме накараха да взема не само резервно бельо, а и резервни дълги гащи, блузи, чорапи и т.н. – да имам за преобличане. Престараха се и с храната – на принципа „докато не хартиса, не е стигнало”. Освен един цял хляб, имах и 5 двойни сандвича, салам и половина, кюфтенца, бучка сирене, бучка кашкавал, пастет, лютеница, кроасани, вафли и, естествено, шише ракия. Никакви стъкларии: ракията (домашна гроздова) налях в метална бутилка от водка Danzka, а лютеницата пресипах в пластмасово бурканче от катък. Стъклата, освен че тежат излишно, имат и гадния навик да се трошат. Още помня как едни нещастни момчета отърваха бутилка „Пещерска” точно пред хижата и тя се строши… трагична история.

Прилапах един сандвич, който си бях нагласил от предната вечер, и в 6:50 потеглих. Дааа… вярно казват: на туриста раницата е тежка, но главата е лека. В 7:00 трябваше да се доставя пред „Плиска”, за да взема Иван и Люси – последната щях да позная по описанието, защото се бяхме чували само по телефона. Закъснях само с 3 минути, което не попречи на Иван да ми звънне да пита дали съм тръгнал. Минах по локалното, за да мога да ги натоваря спокойно.

И така, натоварихме се в рендето и потеглихме към Габрово. Времето си изглеждаше съвсем нормално смотано – тъмно, намръщено небе, ситен дъждец и мъглица. Също както обещаваха синоптиците. А щастие нямаше много коли по пътя и се придвижвахме почти по разписане. Според предварителната програма трябваше да се доставим в 10:00 на хижа „Партизанска песен”, където ще ни чака по-голямата част от групата (тръгнали от Дряново). Слабият ми стомах, обаче, прецака работата – след няколко спирания по пътя, потеглихме от OMV в Габрово около 9:49. За това като излязох от града настъпих колата по завоите към Узана. Не че имахме чак толкова точно разписание – просто не обичам да закъснявам. Обаче около Зелено дърво се натресохме на ужасна мъгла – виждаше се една 1-2 метра пред колата. За това запъплих с 20-30 километра в час, които също си бяха постижение за тези условия.

Ако не бях карал по този път поне 20 пъти, щях да изпусна отбивката. Но понеже съм минавал и преди, макар и не в последните 2-3 години, се ориентирах лесно. Около километър преди отбивката успях да идентифицирам „завоя” – странно наименование на един завой по виещ се планински път, от което дава името на най-голямата ски пистичка района („Пистата на завоя”). След него започнах да се оглеждам за каменен зид от ляво, който предхожда чешмата „Дядо Георги”. Там е и отбивката вдясно за хижите „Хлебна” и „Партизанска песен”. Щом свърнах по малкото пътче, веднага оцених че скоростта ми до този момент е била шеметна. Защото към мъглата се прибави и супер разбита настилка, съвсем не по вкуса на френска кола от средно висок клас. Но баба Гуна (както обичам да наричам Лагуната) за пореден път доказа, че не е за подценяване и така успяхме да стигнем до явката сам с половин час закъснение.

Както казах, нямахме точно разписание. За това вместо да ни посрещат 9 изнервени души, открихме нашите другарчета седнали в столовата да пият чай и кафе и да ядат баница. Не беше трудно да ги идентифицирам предвид глъчката, която пораждаха. Винаги когато тръгна по баирите с Лелята и нейната компания, най-много ме мъчи мускулната треска на скулите – толкова е весело с тях. Честно казано, от настоящата подборка познавах само Лелята, Пачо и Снежа. Май съм виждал и Стефан, но не съм сигурен. Но в такава весела и жизнерадостна компания се влиза лесно. Докато си допият чайовете аз не се притесних да се събуя по боксерки насред столовата, за да си нахлузя наколенките. Предвид приветливото време и огромният шанс да завали докато мааме крачоли, нахлузих върху дънките и едни шушлякови гащи които долу-горе спасяват при слаб дъждец. Екипировката ми се допълваше от любимата ми байкърска ветровка „The North Face” на гърба и супер грозни, но супер здрави, удобни, непромокаеми, дишащи и т.н. перфектни за баири обувки HanWag Lima GTX.

И така, към 11:10 зарязахме колите пред „Партизанска песен” и потеглихме по до болка познатия маршрут към хижа Мазалат. Времето беше перфектно предвид прогнозите, т.е. не само че нямаше гръмотевични бури, ами даже и не валеше много. Мъглата и лекото росене не се борят. Сърцето ми пееше – за първи път на баирче след почти 3 години в града! И то с такава готина компания… Естествено, както и знаех предварително, само на десетина минути след началото на похода калта стана брутална. Пролема на този маршрут е, че през първия час (до местността Корита) се върви по разни горски пътища, които винаги са супер разровени от камионите с дърва, които минават по тях. На едно място нещата станаха толкова гнусни, че аз и Лелята се отделихме от пътя и се качихме на близкото било, за да не вървим из калта („близко“ ще рече, че се качвахме само двайсетина минути). Точно когато наближихме билото, в мъглата пред мен се появи странна гледка: една горска самодива, която се събу и започна да облекчава физиологичните си нужди. С лелята изчакахме да свърши природосъобразната си дейност и да си вдигне гащите, преди да се приближим и да установим, че всъщност това са мъж и жена – хора, туристи като нас. Всъщност мъжът също беше клекнал по негови си дела, но вече бяхме прекалено близко за да се правим на разсеяни и просто го поздравихме с „Добър ден”.

Както и очаквах, пътя по билото (зелена маркировка) беше далече по-лесен от „официалния” (червена маркировка). Проблем бяха само многото нападали (отрязани или изкоренени) дървета и клони, които трябваше или да прескачаме, или да заобикаляме. Все пак, може би заради забавянето ни при изкачването на билото, основната група стигна преди нас до чешмата на Корита. Там имаше пак традиционното похапване на вафли и пиене на истинска планинска вода. Някъде там се пораздигна и мъглата, т.е. видимостта нарастна до главозамайващите петдесетина метра. Което не беше никак достатъчно за нашия фотограф Калин, който нямаше търпение да изпита странният си DSLR Sony Alpha нещо-си.

Около стотина метра след чешмата на Корита изкачването свършва и пътеката тръгва по равното – първо подсича връх Корита, после минава през една поляна със стотици мравуняци, шмугва се отново в гората и подсича от далеч върховете Голям и Малък бухал. По тази пътека калта беше далече по-малко от тази по пътя до Корита, но все пак си имаше, колкото да не е скучно. Тук-там имаше и по някоя стара спечена снежна пряспа, колкото да си избършеш подметките преди да ги изкаляш отново. И така, лека-полека стигнахме до края на гората и арката на национален парк „Централен балкан”. Която вече не е арка – бурните ветрове през зимата са я начупили и стърчат само коловете. От там до хижата има двайсетина минути изкачване, но на мен вече започна да ми става много. Годините мързел в градски условия са се отразили благотворно на шкембенцето ми и негативно на трекинг (и клекинг) уменията ми. Последните стотина метра имах чувството, че раницата ми е пълна с камъни.

Но когато най-после се доставихме в хижата, живнах. Това е странен феномен, който съм забелязвал десетки пъти. Колкото и тежък да е прехода (ходил съм 10 часа в страшна жега от Рибни езера до Мальовица); колкото и да си останал без сили (веднъж буквално заспивах крачейки в снега в последните метри пред Дерменка); колкото и да си разглобен (като след безкрайното слизане от Близанците към Грънчар); влезеш ли в хижата, умората сякаш е изпарява.

И така, кален до (малко над) коленете и ухилен до (малко под) ушите, се доставих в хижа Мазалат в събота следобед. Хвърлихме раниците в спалното и окупирахме една голяма маса в столовата. И беше хубаво.

(може би следва продължение)

 Posted by at 17:28

Връх Мазалат

 Общи  Коментарите са изключени за Връх Мазалат
май 032009
 

Най-злия, вляво.

Mazalat

Вдясно от него са Пиргос и Малкия къдемлия, вижда се и малко от билото на Големия къдемлия (трите образуват масива Триглав).

А това е хижа Мазалат, на около 4 часа от Къдемлията и на 5-6 часа от връх Мазалат:

Mazalat

Над хижата се вижда баирчето Вълчата глава
.

 Posted by at 9:33

Поздрави от Мазалат

 Общи  Коментарите са изключени за Поздрави от Мазалат
май 022009
 

Днес, въпреки заплахите от скапано време, се доставих до хижа Мазалат. При това без да ни вали никакъв дъжд.

Понеже не съм ходил на планини от доста време, сега гърба ми е доста схванат (от раницата). А понеже не съм ходил с дряновската група от още повече, вече ме болят и скулите (от смях).

Нека ми е лошо 😉

 Posted by at 18:13