Варианты математического аппарата для описания проблем масштабирования динамической инфраструктуры

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

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

F(v) = G(f 1(v), f 2(v),..., f p(v))

Суперкритерий позволяет упорядочить альтернативы по величине F(v), выделив, тем самым, наилучшую альтернативу для этого критерия. Основной проблемой при данном подходе является определение именно значений вклада критериев и обоснование того, почему один из них больше другого. В таких случаях чаще всего обращаются к статистическим выкладкам, но для данной проблемы такое решение невозможно, так как в принципе не может быть сравнения производительности системы и типа лицензирования – это два несвязанных понятия, но, в то же время, они оба влияют на масштабирование системы. Выходом из данной ситуации является обсуждение значения факторов, влияющих на масштабирование системы, непосредственно с заказчиком. В этом случае проводится анализ потребностей заказчика, и выявляются наиболее значимые показатели. Для определения общей модели такой подход невозможен, но с течением времени можно собрать статистику и уже на ее основе выставлять значения каждого критерия.

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

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

Для формального описания системы обозначим через Х все множество альтернативных решений, q_j – значения критериев (уровни притязаний), а точку их пересечения в р-мерном пространстве критериев х* - целью или опорной точкой. Важно отметить, что целевая точка может оказаться как внутри, так и во вне Х, т.к. уровни притязаний задаются без точного знания структуры множества Х в пространстве частных критериев. Идея оптимизации состоит в том, чтобы начав с любой альтернативы, приближаться к х* по некоторой траектории в пространстве.

С учетом того факта, что одним из ключевых показателей любой системы является ее производительность, а уже затем идут такие характеристики, как доступность, надежность, безопасность и т.п., поэтому на одной из осей необходимо отразить производительность системы. Единицы измерения производительности зависят от рабочей нагрузки, под которой понимаются не только не приложения, но и операционная система и промежуточное программное обеспечение. Например, для SAP единицей измерения производительности будет SAPS. В случае вертикального масштабирования по другой оси должно откладываться количество ресурсов в системе (количество процессоров, планок памяти), для горизонтального – количество узлов (серверов или систем хранения данных). На данном этапе получается лишь зависимость производительности системы от числа ее компонент, поэтому возникает вопрос о влиянии смены поколений ресурсов, периоде поддержки аппаратной части программной. Для этого необходимо ввести третью ось, где будет отсчитываться время. Именно по данной оси будут ограничиваться области, связанные, например, со временем лицензирования программного обеспечения на определенном типе процессоров. Предполагается, что подавляющее большинство факторов, влияющих на масштабируемость, можно выразить через соотношения, основанные на трех позициях – производительности, количества элементов в системе и времени.Итого при решении следующих задач можно ограничить область, где будет находиться решение, проведя следующие действия:

1. Выразить формулой зависимость производительности системы от числа элементов
2. Оценить периодичность выпуска и нового поколения ресурсов и временные рамки целесообразности перехода.
3. Оценить периодичность выпуска новых версий программного обеспечения и очертить рамки поддержки им аппаратного обеспечения.

Выводы

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

Список литературы

1.     Дубов Ю.А., Травкин С.И., Якимец В.Н. Многокритериальные модели формирования и выбора вариантов систем. – М.: Наука, 1986 – 296 с.

2.     Спиряев О. Вертикальное и горизонтальное масштабирование систем // BYTE. 2004. №3 (67).

Проблемы, возникающие при масштабировании инфраструктуры.

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

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

Чаще всего проблема масштабируемости решается на программном уровне, но в данной статье предметом масштабирования является динамическая инфраструктура. Динамическая инфраструктура представляет собой комплексный подход к трансформации ИТ с целью решения следующих задач:

• ·        Улучшение сервиса
• ·        Сокращение расходов
• ·        Управление рисками

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

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

Можно привести более простой пример: предполагается, что фирма закупает определенное число единиц оборудования, которое способно обеспечивать определенный уровень производительности, достаточный для удовлетворения требуемых уровней сервиса. Руководство заказчика оценивает, что через год клиентская база увеличится на 30%, что ведет за собой большую нагрузку на систему. Очевидно, что абсолютно не рационально покупать новые сервера и системы хранения данных (СХД) для удовлетворения новых потребностей, что снова приводит к вопросу масштабирования существующей инфраструктуры, поэтому нужен быстрый механизм по выделению ресурсов.

Здесь необходимо отметить два вида масштабируемости: вертикальное (scale-up) и горизонтальное (scale-out)[2]. Возможны случаи по использованию данных типов как раздельно, так и совокупно в одном решении. Под вертикальным масштабированием подразумевается увеличение ресурсов в рамках одного сервера, т.е. это может быть вставка в свободные слоты дополнительной памяти, добавление процессоров и т.п. Под горизонтальным масштабированием понимается увеличение количества серверов, соединенных в один вычислительный узел, другими словами, фактически это кластер, причем в данном случае не важно, какого он типа: Active/Active илиActive/Passive.

Проблемы при вертикальном масштабировании

С каждым годом появляется все больше и больше различных моделей процессоров, которые более производительны и потребляют меньше энергии. В связи с этим возникает вопрос: какое именно поколение использовать? Более того, проблема стоит не столь остро, когда строится новая инфраструктура, где основным сдерживающим фактором является цена. В случае же с модернизацией инфраструктуры отправной точкой является именно существующая инфраструктура и ее составляющие. Предположим, что компания уже имеет сервер Power595 с 32 процессорами Power6, имея еще 32 слота свободными и доступными для заполнения, но в этот момент на рынке появляются новое семейство процессоров Power7, которые превосходит предшественника по всем параметрам. Заказчик рассчитал, что для поддержки его новых задач производительности 32 процессоров поколения Power6 вполне достаточно, но возникает вопрос: что делать при дальнейшем росте потребностей бизнеса и необходимости в выделении большего количества вычислительных мощностей? Что более целесообразно: дозаполнить существующий сервер, который несет большие операционные расходы, или затратить средства на новый, более производительный сервер с меньшими операционными расходами? Здесь существенное влияние оказывает также вероятность как прогнозируемых, так и непрогнозируемых пиковых нагрузок на систему, и в случае непредвиденных ситуаций необходимо иметь запас для увеличения производительности.

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

Очевидно, что инфраструктура строится для поддержки приложений, что также вносит некоторые сложности и ограничения при проектировании. При более детальном анализе можно сделать вывод, что проблема намного более многогранна, чем может показаться на первый взгляд. Первый аспект – при расширении функционала приложений необходимо увеличение вычислительных ресурсов, но вопрос состоит в том, как определить величину кратности увеличения? С другой стороны, данный вопрос интересен не только по отношению к приложениям, но и к увеличению нагрузки на систему в целом, например, при увеличении количества клиентов. Равен ли коэффициент кратности увеличения количества пользователей коэффициенту кратности увеличения производительности инфраструктуры? Второй аспект при поддержке приложений инфраструктурой заключается в различии в поколениях как программного, так и аппаратного обеспечения. Срок службы серверов семейства Power может составлять 10 лет, а за это время версии приложений могут обновиться не один раз и может оказаться, что новые версии программного обеспечения уже не поддерживают старые процессоры. С другой стороны, при отсутствии обновлений программного обеспечения и покупке более современного аппаратного обеспечения, приложения могут работать нестабильно и некорректно либо использовать не все представленные возможности, снижая тем самым производительность системы.

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

Проблемы при горизонтальном масштабировании

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

На выборе правильной нагрузки для распараллеливания стоит остановиться более подробно.Важно различать следующие типы кластеров: Active/Passive  иActive/Active. Для вертикального масштабирования данное разделение было не столь существенно, так как изменялись компоненты серверов, а не их количество, в случае горизонтального масштабирования данный вопрос, напротив, очень важен. В случае Active/Passive только один узел является активным и обрабатывает задачи, а другие узлы находятся в «горячем» резерве, способные продолжить функционирование системы при отказе основного узла. Для Active/Active кластера характерно распараллеливание задач, т.е. параллельная обработка на всех узлах кластера, что, безусловно, повышает эффективность выполнения системы, но в то же время и усложняет ее. Первый тип кластера встречается намного чаще из-за легкостипри установке и способности обработки практически любой задачи, второй тип более сложен, но более эффективно использует имеющиеся ресурсы и исключает простой второго сервера. Примером Active/Passive кластераможетслужить Microsoft Cluster Services илиVeritas Cluster Server, Oracle Real Application Cluster или DB2 PureScale – примеры Active/Active кластера. При рассмотрении вопросов масштабируемости наибольший интерес представляет именно Active/Active кластер, способный производить одновременную обработку на нескольких узлах, что позволяет увеличивать или уменьшать число элементов, изменяя производительность системы. Для Active/Passive кластера число элементов не оказывает влияние на производительность решения, а больше влияет на отказоустойчивость, создавая дополнительные узлы для резервирования.

Для Active/Active кластера важно рассчитывать количество узлов в системе, при которых производительность системы в целом будет максимальна. Рекомендованное число узлов, как правило, не превышает 8, т.к. при большем числе накладные расходы на внутренние связи между элементами системы возрастают, что приводит к понижению производительности. С другой стороны, важно учитывать рабочую нагрузку при выборе количества узлов в кластере, т.к. при возможности разделения нагрузки на независимые потоки число узлов в кластере возрастает в разы.

При горизонтальном масштабировании серверов не всегда существует возможность создавать систему на полностью идентичном аппаратном обеспечении, что приводит к проблеме существования различных доменов. Предположим, на предприятии для поддержки текущих нужд находится сервер определенной производительности, но в связи с постоянно увеличивающейся нагрузкой и необходимостью обеспечить высокую доступность системы внедряется кластерная реализация. В качестве второго узла был куплен менее производительный сервер в целях экономии с тем предположением, что 70% нагрузки будет на старом узле и 30% на новом, поэтому новый сервер может иметь меньшую производительность. Но был не учтен тот факт, что несмотря на формальное присутствие решения по обеспечению высокой доступности, при отказе старого, более производительного сервера система хоть и мигрировала на новый, но из-за слишком большой задержки при выполнении запросов вследствие меньшей производительности второго сервера,была прекращена работа всех приложений, обращающихся к размещенной на указанных серверах системе. Формально система обладала способностью функционировать при отказе одного из серверов, но на практике оказалась неспособной продолжать работу из-за разных по производительности доменов системы.

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

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

Влияние температуры в ЦОД на надежность оборудования

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

Также важно отметить, что уже при температуре 27С надежность оборудования становится меньше примерно в 1,3 раза или на 30%, из чего можно сделать важный вывод: покупка дорогостоящего оборудования с высокими показателями надежности (MTBF) при неправильном размещении будет отнюдь не лучше, чем покупка менее дорогого оборудования, но расположенного в комфортных условиях. 

Температура[1]	Среднее значение коэффициента отказа	Минимальное значение коэффициента отказа	Максимальное значение коэффициента отказа
15	0,72	0,72	0,72
17,5	0,87	0,8	0,95
20	1	0,88	1,14
22,5	1,13	0,96	1,31
25	1,24	1,04	1,43
27,5	1,34	1,12	1,54
30	1,42	1,19	1,63
32,5	1,48	1,27	1,69
35	1,55	1,35	1,74
37,5	1,61	1,43	1,78
40	1,66	1,51	1,81
42,5	1,71	1,59	1,83
45	1,76	1,67	1,84

---

[1] http://tc99.ashraetcs.org/documents/ASHRAE%20Whitepaper%20-%202011%20Thermal%20Guidelines%20for%20Data%20Processing%20Environments.pdf

Данные в таблице являются открытыми и представлены независимой ассоциацией ASHRAE (American Society of Heating, Refrigerating and Air Conditioning Engineers)

На графике более наглядно отражена тенденция к увеличению количества отказов и, как следствие, уменьшению MTBF с ростом температуры. Можно считать, что при температуре в 45 надежность системы оказывается в 2 раза меньше, чем она заявлена согласно паспортным характеристикам, что вносит коррективы в расчет надежности системы в целом.

В итоге представленные показатели можно использовать в следующих подходах:

1.  Сравнивать надежность двух решений при равных температурных условиях в ЦОД и при расчетах вносить коррективы с учетом коэффициента изменения надежности оборудования
2. Показывать, что для обеспечения требуемого уровня надежности оборудования необходимы определенные температурные условия в ЦОД

Швейцария. Женева. Жесткий OFFTOP 10

День 7. 

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

Закон подлости все же работает. Хотя сегодня он сработал, в общем-то, в позитивную сторону - я умудрился найти халявный WiFi посреди буквально поля, причем еще и с видом на Женевское озеро. Вот найти бы мне его парочкой дней раньше.. Хотя, думаю, ничего бы существенно не изменилось: я бы не поехал в Лозанну? - нет. Я бы не пошкл гулять по старой части города? - нет. Возможно я бы приходил туда вечером, хотя топать до той волшебной лавочки минут 25, что по Женевским масштабам ой не сильно близко да и идти надо по какому-то афроамериканско-индусскому району с кучами битого стекла, дешевыми апартаментами и с майками, висящими на дереве для просушки после стирки. Фото, к сожалению, нет, т.к. мне было как-то стремновато фоткать это дело на виду у 3х черных и 2х мамашек с кучей детей.

Сегодня в лучших традициях меня спрашивали, как куда-то пройти и вообще, в чем смысл жизни. На второй вопрос ответить затруднялся, а на первый одной девушке с очень приятным английским акцентом нашел WTO - world trade organization, расположенную фактически в том же парке, где я и сидел - спасибо Google за карту. Лично мне туда идти было лениво, так что я остался наслаждаться видами озера и читать про HP SuperDome. Вот все сейчас вспомнили, что вообще-то я как бе занимаюсь системной архитектурой и вообще блог то о ней самой.

Накупил шоколадок, так что кто хочет получить сувенир - пишите, звоните, количество презентов явно ограничено - чую, будет драка. 

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

Швейцария. Женева. Жесткий OFFTOP 9

День 6.

 Сегодня нашел для себя место, где теоретически было бы неплохо жить. Речь идет о Лозанне, хотя надо признать, что особо энтузиазма при поездке туда я не испытывал, считая, что ну что там может быть интересного – озеро видно и из Женевы, с Церматтом с точки зрения видов гор мало что вообще может сравниться, ну а музей Олимпийских Игр как-нибудь и без меня проживет. Другое дело, что в Женеве в воскресение, когда все закрыто, делать совершенно нечего, то выбора у меня толком и не было. 

«С места в карьер» - именно так я бы охарактеризовал свои первые действия в Лозанне. Дело в том, что исторический центр или старый город с ратхаусами и старыми улочками находится на горе. И здесь я в очередной раз на практике понял принцип: «Не теряй высоту». Верхняя часть города настолько сильно испещрена маленькими улочками, идущими то вверх, то вниз, соединяя холмы, что приходилось выбирать те, которые шли примерно на одном уровне, чтобы лишний раз не тратить сил на подъем. Разумеется, это Европа, более того, Швейцария, и такая вещь, как лифт у них есть, но его же еще найти надо. Все же за эту неделю я очень много раз то поднимался на холм, то спускался – это явно останется в памяти надолго.

Надо признать, что историческая часть оставила только благоприятное впечатление в отличие от Женевы, хотя схожих черт очень много. Непонятный феномен, но факт остается фактом – Лозанна мне понравилась. Вот такие виды открываются из старого города:

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

Несмотря на то, что Женевское озеро оно и  в Женеве такое же, я все равно спустился к воде на метро. Хотя метро это назвать сложно: размер состава где-то 2 наших обычных вагона и идет он преимущественно по верху, заезжая в туннели только для остановок. На побережье почему-то пришла на ум связь с Майями – не знаю почему. Очень понравились местные катамараны с уже встроенным трамплином:

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

 

В итоге пробрался – куда же я денусь. Сам музей произвел опять же очень благоприятное впечатление, особенно запомнилась полная коллекция факелов для олимпийского огня с первых ОИ, а также медали 3х достоинств опять же со всех игр. Неоспоримым достоинством музея была прохлада – ну улице минимум 28, а на солнце так вообще жуть, а тут кондиционеры.

Умудрился купить студенческий билет без ISIC, показав карточку для метро – побольше убеждения, и к тому же, я же ничего не нарушил – официально я же студент. Пустячок, а приятно – сэкономил 10 франков. Интересный факт: у них ведется статистика посетителей, кто из какой страны. Разговорившись, узнал, что наиболее популярны швейцарцы, затем французы, затем китайцы. Китайцев там действительно было много – на улицах их так не видно, а тут прям как будто магнитом притянуло.

Вот еду в поезде обратно в Женеву и удивляюсь: ну как такие люди, как швейцарцы, не могут сделать в вагон поезда кондиционер? Причем поезд то идет часа 4 от одной конечной до другой – странно это. 

Напоследок фотка меня на фоне Женевского озера дабы не забыли, как я выгляжу.

Швейцария. Женева. Жесткий OFFTOP 8

День 5.

Сегодня отметил день Десантника. «Почему?» – спросите вы. Это неправильный вопрос. Правильный вопрос – «как?». Хотя мне кажется, что ответ на уже этот вопрос довольно очевиден: разумеется, искупался в фонтане. Скажем так, грех не искупаться в, наверное, самом известном фонтане в мире высотой 130 метров. Всю десантуру переплюнул: у них то Парк Горького, то ВДНХ или Поклонная гора – в целом, мелочи, а тут фонтан, который видно из самолета. Причем «купаешься» весьма своеобразным способом, пытаясь пробраться на пирс, т.е. тебя брызгами окатывает с ног до головы, но сначала левую сторону, а, когда идешь обратно, правую – в итоге, все равно весь мокрый. Бежать не получится – каменная дорожка шириной около 2 метров и жутко скользкая.  

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

Надо признать, что Женева – весьма небольшой городок, мне хватило 2 часов вчера вечером, чтобы обойти те места, куда стоило бы сходить. Причем я навернул где-то 3 круга, выходя все время практически в одну точку – заблудиться невозможно, у меня и карты то с собой не было – просто пошел и всё, ноги есть, они двигаются, что еще нужно? Ориентировался я по вывескам на домах на набережной, чтобы попасть назад в отель – надо было выйти на набережную и найти футбольный клуб. Да, я предпочитаю запоминать ассоциациями - имеется в виду Zenith. Кроме того, так получилось, что я шел от Старбакса до Старбакса – соблазнился, и пришлось взять капучинку и с ней весело шагать по просторам. Напевать хором было не с кем.

К слову, город очень спокойный. Я честно пытался найти место потусить, повторюсь, я обошел весь центр, но ничего. Вообще ничего. А между прочим, вчера была пятница. Я пытался определить по направлению движения прилично и соответствующе одетых девушек, но кто-то тупо пришел на площадь и встал (неужто там зажигать собрались?), кто-то, оказывается, просто гулял, кто-то сел в машину и уехал. С другой стороны, в Стокгольме тусовочная зона выделена отдельно и находится отнюдь не в центрально-исторической части. Как говорится, на сегодняшний вечер Challenge accepted – надо же сравнивать клубы.

Вообще, складывается стойкое ощущение, что  в Женеву возят, по всей видимости, только русских, правильнее сказать, русскоговорящих. Вообще от засилия русских в Женеве я устал – стоит пройти буквально несколько сотен метров, так обязательно услышишь русскую речь либо натолкнешься на экскурсию. Хотя вот в Церматте в первый день я пару раз тайком оглянулся на русскую речь и увидел … японцев О_о. Нет, ну мало ли - всякое бывает,  и они заговорить могут, но вывод очевиден – ты слышишь то, что хочешь услышать. На второй день от этой проблемы я избавился, научившись уже узнавать японский, несмотря на то, что они по большей части молчат. Поэтому здесь в Женеве именно русская речь – либо украинцы, либо русские, а никак не японцы.

Кстати, я, по-моему, становлюсь местной достопримечательностью – по моей физиономии и внешнему виду ведь никак не скажешь, что я русский, а я, к тому же, сижу рядом с самой длинной скамейкой в Европе, куда водят толпы туристов – вот все и на меня смотрят как на местного аборигена за столом и с ноутбуком. Причем 4 группы из 5 – русскоговорящие. Зато нашел для себя единственный довод ездить на массовые экскурсии – тут тусуется много симпатичных девушек. Правда беда одна – они все с родственниками, причем ладно бы с не менее симпатичной сестрой, а то ведь и с мамой, и с папой и с тяжелой артиллерией в виде бабушки с какой-нибудь подругой.

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

Анекдот в тему:

Гопник, напавший в подворотне на Анатолия Вассермана, случайно получил высшее образование.

:)

Забавный у них университет – на ступеньках перед центральным входом белый и черный (инь-янь) устроили батл. Имею  в виду танцевальный батл. К ним подошла толстая девочка, и они перестали. Видимо, поняли, что надо менять свой стайл, раз только такие клюют. Сочувствую.

Проходя по парку, в очередной раз отметил превосходство Европы над Россией – у нас так просто полежать на травке с детьми не выйдешь посреди города. Хоть в тех же Сокольниках, которые, кстати, еще и не сильно близко к центру, просто так ведь не полежишь на травке недалеко от входа. А тут – пожалуйста. На самом деле, не сказать, что в Женеве много парков, но зелени много. Да и вообще, повторюсь, город то небольшой: о чем вообще можно говорить, если на карту города добавлен аэропорт, до которого вообще доплюнуть.

Что окончательно понял, так это то, что по музеям ходить вообще не тянет. Все путеводители весьма настойчиво рекомендуют идти в музей Искусства, в Женеве все же Руссо родился, но раз это путеводитель советует, значит, точно не пойду. Такими темпами придется ехать в Лозанну, ибо завтра я погуляю по правому берегу (Переправа, переправа, берег левый, берег правый!) до здания ООН и др.

Фотографировать в Женеве нечего – это тебе не Люцерна; то ли у меня глаз уже пресытился европейскими зданиями, то ли действительно делать тут нечего и смотреть не на что.

 А вообще, надо еще раз отметить день десантника – что-то аЦЦки жарко.

Швейцария. Женева. Жесткий OFFTOP 7

День 4. Часть 2.

«Ну здравствуй, Женева!» - зычным голосом сказал я, расставив руки в стороны в тот момент, когда моя нога ступила на платформу Женевского вокзала, попутно чуть не прибив взмахом рук пару хрупких япошек и до смерти испугав группку француженок. Эх, мечты, мечты – воспитание не позволяет так делать, а было бы крайне забавно.

Явно завидую швейцарцам в том, что они знают 4 языка – 3 государственных + английский. Это я к тому, что та же самая страна, а уже будь добр вместо «Danke» говорить «Merci», а в Церматте, между прочим, свое наречие немецкого языка, причем не швейцарское, а именно свое. Причем, как говорили мне немецкие девчонки в Стокгольме, немец швейцарца не поймет. Вот такое вот многообразие на несчастных 500 км от силы. У нас то на 500 км только за Кострому заедешь немного, но мы то все друг друга понимаем на ура. А с выпивкой становимся вообще как братья. Но это я отвлекся.

Первое впечатление, когда вышел из вокзала: «Оо, машины! Сколько же машин! Сколько людей!» - после Церматта, где ездят только электромобили-газонокосилки-мячикидлягольфа-собиралка, даже обычная Шкода будет казаться верхом человеческой мысли в автомобилестроении. 

Второе впечатление на меня в буквальном смысле нахлынуло: +30 за бортом. Нет, в Церматте днем уличный термометр тоже показывал +30, но было как-то не так фигово. Опять повторюсь: горы.. А здесь просто ужас, поэтому гулять пойду ближе к ночи – в данный момент духота невообразимая – у меня же на Женеву целых 3 дня, я за завтрашний день уже всё обойду.

Швейцария. Церматт. Жесткий OFFTOP 6

День 4. Часть 1.

Иногда я бываю чересчур наивен. Вчера, когда в Церматте шел дождь, я подумал, что это ведь хорошо – наверху на леднике наверняка идет снег, значит бело-коричневые участки присыпет, а склон станет вообще по-зимнему хорош. В таком приподнятом настроении я и вышел в сторону подъемника.

В итоге сегодня я попробовал швейцарское троеборье. Почему швейцарское? Потому что, насколько я помню, троеборье = бег+плавание+велосипед или как-то так. В зимних видах спорта есть двоеборье, но у меня получилось нечто совсем невообразимое. Понятно, что первый вид банален до противности – это горные лыжи. Вот удивительно то, да? Затем горные лыжи плавно перешли в коньковый спорт или шорт-трек – назвать снегом то, что было под ногами, точнее лыжами, никак нельзя. Это был великолепного качества, практически идеальный лед.

Не скажу, что я был как корова на льду, не настолько я уж не умею кантами цепляться за склон, но удовольствия не получил никакого – в коньках было бы намного сподручнее, пришлось кататься на немного большей скорости, чем обычно, а затем больше тормозить в конце, т.к. выписывать дуги было непросто. Тут то я и понял, что как-то подозрительно мало было спортсменов – 3 недобитых француза, словенцы вымерли, школа в желтых куртках (ага, группа в полосатых купальниках) также была сильно урезана в представительстве на склоне.

Помнится, я обозначил сегодняшнее катание как троеборье: лыжи есть, коньки тоже – что же третье? Казалось бы, логичным продолжением были бы беговые лыжи (сломался подъемник, например, и пришлось вместо бугеля на своих двоих ехать на плоскости) или прыжки с трамплина (ну не рассчитал, вылетел с трассы, пролетел чуток), на худой конец

могла бы стрельба (биатлон то популярен), но тут стрелять было не во что, а в кого-то все же нельзя, да и нечем. В итоге третьим видом спорта были все же лыжи, но водные! На высоте 4000 метров среди льдов и дикого ветра была немаленьких размеров лужа, которую надо было форсировать, чтобы попасть на подъемник. Конечно, никакой катер меня не тянул, разгона хватило, чтобы не застрять посередине, но это было потрясающе проехаться по луже на высоте 4000 метров среди льдов и снега.

В остальном все довольно-таки обыденно. Ради экскурсии зашел в Макдоналдс – надо же сравнивать их в каждом городе. Выводы:

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

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

3. Выбрасываешь весь хлам сам в дырку, где крупно написано “Danke”.

4. И да, Биг Мак, чизбургер, картошка и кола обошлись мне в 16 франков (600 рублей). Да да, у нас можно за эти деньги 3 раза поесть в том же Макдаке (чизбургер, кстати, стоил 2,5 франка = под 100 рублей), но все равно еда в Макдаке сильно дешевле общего уровня, как и у нас.

Сейчас уже еду на поезде в Женеву, в очередной раз удивляясь, насколько же тихо и плавно может идти поезд на скорости явно больше сотни км/ч. В целом, Церматт понравился, если хочешь спокойно-спортивного образа жизни – это не взаимоисключающие понятия. Для людей, которые привыкли к постоянному движению, на 3й день там уже станет скучно, но, на мой взгляд, при возможности посетить Церматт обязательно стоит, хотя бы ради того, чтобы забраться на 4000 метровую высоту и схватить пролетающие самолеты за крыло или попробовать summer skiing.

Напоследок немного фотографий гор: