В докладе, подготовленном Программой ООН по окружающей среде (UNEP), Фракфуртской школой финансов и управления и Bloomberg говорится, что только за прошлый год объем инвестиций в энергетику на основе возобновляемых источников (в первую очередь на базе солнечных установок и ветряных генераторов) составил порядка $270 млрд, показав рост 17% год от года. Всего же с 2004 года во всём мире в альтернативную энергетику было вложено около $2 триллионов, лидируют здесь Китай, США и Япония.

На почве высокой стоимости нефти в среднем в 2014 году, возобновляемая энергетика составила почти половину новых, введенных в строй, мощностей – об этом говорит директор Unep Ахим Штайнер. По мнению президента Франкфуртской школы финансов и управления Удо Штефенса, более низкая цена на нефть окажет негативное воздействие на инвесторов лишь в странах-экспортерах энергоресурсов.

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

Лидером по инвестициям в возобновляемые источники энергии в прошлом году стал Китай с вложениями в объеме $88,3 млрд, США – $38,3 млрд и Япония с $35,7 млрд. 92% от общего объема инвестиций приходится как раз на солнечные и ветряные электростанции.

Forbes отмечает, что если еще недавно (3-5 лет назад) солнечные панели были очень дорогими и их установка часто не имела экономической целесообразности, то сейчас ситуация сильно изменилась. Более того – через 10 лет солнечные панели и электростанции на их основе могут стать основным и наиболее дешевым источником электроэнергии, особенно в странах с большим количеством солнечных часов в году.

Уже сейчас киловатт-час электроэнергии, полученной с помощью солнца в таких странах, как ОАЭ, Бразилия и Уругвай стоят ниже 7 американских центов. Для сравнения – сейчас в Германии один киловатт-час полученный с угольной электростанции оценивается в 9 центов, с АЭС – в 11 центов.

ссылка на оригинал статьи http://megamozg.ru/post/13828/

Холдинг «Газпром-медиа» запустил программу оптимизации, которая предусматривает закрытие бесприбыльных, неактуальных проектов, а также проектов, у которых есть конкуренты внутри самого холдинга. Новое руководство «Газпром-медиа» сейчас также пересматривает незавершенные сделки, сообщили «Известия». Сделки, признанные невыгодными, могут не состояться. Одна из таких сделок — продажа 74,7% акций ЗАО «Рутьюб» госкомпании «Ростелеком».

Три проекта, которые входят в ЗАО «Рутьюб», включая Rutube, Now.ru и Zoomby, дохода не приносят. Кроме того, эти сервисы работают на сокращающемся в текущих условиях рынке рекламы. Поэтому, скорее всего, они получат новую концепцию развития внутри холдинга. «Ростелеком», будет работать с собственным проектом Zabava.ru. В начале октября прошлого года сделка с активами ЗАО «Рутьюб» была оценена в 5,5 млрд рублей.

Ранее руководство проекта Zoomby планировало объединить на площадке сразу несколько производителей контента. Привлечь удалось лишь одного партнера, ВГТРК (сейчас телеканалу принадлежит 26% Zoomby). Кроме того, сейчас предлагается несколько разных вариантов развития активов ЗАО «Рутьюб». Скорее всего, контент на всех проектах будет одинаковым, хотя «упаковку» планируют сделать разной.

Пересматривать свою политику «Газпрому-медиа» необходимо, поскольку компания терпит убытки. Так, по данным «СПАРК-Интерфакс», холдинг «Газпром-Медиа» в прошлом году впервые с 2010 года получил убыток в размере 446 млн. В 2013 году компания завершила аналогичный финансовый период с прибылью в 1,28 млрд рублей. Также в плюсе она заканчивала и 2012 и 2011 годы — 636 млн и 715 млн рублей. Акционеры компании стали требовать вывести все СМИ, которые входят в состав холдинга, на уровень окупаемости.

В конце 2014 года произошла смена руководства холдинга. Так, глава совета директоров «Газпром-медиа» уступил свой пост экс-главе оргкомитета Олимпийских и Паралимпийских игр в России и руководителю Volga Group Дмитрию Чернышенко. С новым руководителем пришла и новая команда топ-менеджеров.

ссылка на оригинал статьи http://megamozg.ru/post/13826/

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

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

Ведь главная цель спортсмена — выйти в соревновательный период и выступить на старте в своей лучшей форме, при этом также важно не перетренироваться. Это иногда случается, если уровень молочной кислоты в крови зашкаливает и времени на вывод продуктов распада нет.
Ранее подобные расчёты добывались посредством сложных проверок, ежеминутного анализа крови и сердечного ритма. Однако год назад на Kickstarter запустили проект BSXinsight, который собрал 122 тыс. долларов, чего оказалось достаточно, чтобы наладить производство.
Компании удалось довести проект до конца и не далее как вчера, 31 марта, в продажу поступили первые трекеры BSXinsight. Всего в линейке — три модели: бега, велотренировок и так называемый мультиспорт. Начальная цена устройства — 300 долларов.

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

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

ссылка на оригинал статьи http://geektimes.ru/post/248232/

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

Сегодня в ИТ прочные позиции завоевал подход, основанный на стандартах, – заказчики почти всегда отдают предпочтения стандартным решениям. С уходом эпохи, когда господствовали мейнфреймы, стандарты завоевали прочные позиции. Они позволяют комбинировать оборудование разных производителей, выбирая «лучшие в своем классе» продукты и оптимизировать стоимость решения. Но в сетевой отрасли не все так однозначно.

На сетевом рынке до сих пор доминируют закрытые системы, а совместимость решений разных производителей обеспечивается в лучшем случае на уровне интерфейсов. Несмотря на стандартизацию интерфейсов, стеков протоколов, сетевых архитектур, сетевое и коммуникационное оборудование разных вендоров нередко представляет собой проприетарные решения. Например, даже развертывание современных «сетевых фабрик» Brocade Virtual Cluster Switch, Cisco FabricPath или Juniper QFabric предполагает замену имеющихся коммутаторов, а это не дешевый вариант. Что уж говорить про технологии «прошлого века», которые еще работают, но тормозят дальнейшее развитие сетей и функционирующих в них приложений.

Эволюция сетей. От проприетарных к открытым решениям.

Проводимые в последние годы исследования показывают, что существует разрыв между предложениями вендоров сетевого оборудования и предпочтениями его покупателей. Например, по данным одного из опросов, 67% заказчиков считают, что проприетарных продуктов по возможности следует избегать, 32% допускают их использование. Лишь 1% респондентов уверены, что проприетарные продукты и средства обеспечивают лучшую интеграцию и совместимость, чем стандартные. То есть в теории большинство заказчиков предпочитает основанные на стандартах решения, но предлагаются в основном проприетарные сетевые продукты.

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

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

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

Иерархические и плоские сети

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

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

Трехуровневая архитектура корпоративной сети.

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

Уровень ядра – основа всей сети. Для достижения максимальной производительности функции маршрутизации и политики управления трафиком выносятся на уровень агрегирования/распределения. Именно он отвечает за надлежащую маршрутизацию пакетов, политики трафика. Задачей уровня распределения является агрегирование/объединение всех коммутаторов уровня доступа в единую сеть. Это позволяет существенно уменьшить количество соединений. Как правило, именно к коммутаторам распределения подключаются самые важные сервисы сети, другие ее модули. Уровень доступа служит для подключения клиентов к сети. По аналогичной схеме строились и сети ЦОД.

Устаревшая архитектура трехуровневой сети в центре обработки данных.

Традиционные трехуровневые архитектуры ориентированы на клиент-серверную парадигму сетевого трафика. С дальнейшим развитием технологий виртуализации и интеграции приложений возрастает поток сетевого трафика между серверами. Аналитики говорят (тут тоже) о смене парадигмы сетевого трафика с направления «север—юг», на «восток—запад», т.е. на существенное преобладание трафика между серверами в отличие от обмена между сервером и клиентами.

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

То есть трафик между серверами проходит через уровни доступа, агрегации, ядра сети и обратно неоптимальным образом, за счет необоснованного увеличения общей длины сетевого сегмента и количества уровней обработки пакетов сетевыми устройствами. Иерархические сети недостаточно приспособлены для обмена данными между серверами, не вполне отвечают требованиям современных ЦОД с высокой плотностью серверных ферм и интенсивным межсерверным трафиком. В такой сети обычно используются традиционные протоколы защиты от петель, резервирования устройств и агрегированных соединений.  Ее особенности: существенные задержки, медленная сходимость, статичность, ограниченная масштабируемость и т.п. Вместо традиционной древовидной топологии сети необходимо использовать более эффективные топологии (CLOS/ Leaf-Spine/ Collapsed), позволяющие уменьшить количество уровней и оптимизировать пути передачи пакетов.

HP упрощает архитектуру сети с трёхуровневой (характерной для традиционных сетевых архитектур Cisco) до двух- или одноуровневой.

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

В ЦОД плоская сеть (уровня L2) лучше отвечает потребностям виртуализации приложений, позволяя эффективно перемещать виртуальные машины между физическими хостами. Еще одно преимущество, которое реализуется при наличии эффективных технологий кластеризации/стекирования – отсутствие необходимости в протоколах STP/RSTP/MSTP. Такая архитектура в сочетании с виртуальными коммутаторами обеспечивает защиту от петель без использования STP, а в случае сбоев сеть сходится на порядок быстрее, чем при использовании традиционных протоколов семейства STP.

Архитектура сети современных ЦОД должна обеспечивать эффективную поддержку передачи больших объемов динамического трафика. Динамический трафик обусловлен существенным ростом количества виртуальных машин и уровня интеграции приложений. Здесь необходимо отметить все возрастающую роль различных технологий виртуализации информационно-технологической (ИТ) инфраструктуры на базе концепции программно-определяемых сетей (SDN).

Концепция SDN в настоящее время широко распространяется не только на уровень сетевой инфраструктуры отдельных площадок, но и на уровни вычислительных ресурсов и систем хранения как в рамках отдельных, так и географически-распределенных ЦОД (примерами последних являются HP Virtual Cloud Networking – VCN и HP Distributed Cloud Networking – DCN).

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

Архитектура HP FlexNetwork

Для построения плоских сетей вендоры разрабатывают соответствующее оборудование, технологии и сервисы. В числе примеров – Cisco Nexus, Juniper QFabric, HP FlexFabric. В основе решения HP – открытая и стандартизированная архитектура HP FlexNetwork.

HP FlexNetwork включает в себя четыре взаимосвязанных компонента: FlexFabric, FlexCampus, FlexBranch и FlexManagement. Решения HP FlexFabric, HP FlexCampus и HP FlexBranch оптимизируют сетевые архитектуры, соответственно центров обработки данных, кампусов и филиалов предприятий, позволяя по мере роста поэтапно мигрировать от традиционных иерархических инфраструктур к унифицированным виртуальным, высокопроизводительным, конвергентным сетям или сразу строить такие сети на основе эталонных архитектур, рекомендованных НР.

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

HP FlexFabric поддерживает коммутацию в сетях до 100GbE на уровне ядра и до 40GbE на уровне доступа, использует технологию HP Virtual Connect. Внедряя архитектуру FlexFabric, организации могут поэтапно перейти от трехуровневых сетей на оптимизированные двух- и одноуровневые сети.

Заказчики могут поэтапно переходить от проприетарных устаревших сетей к архитектуре HP FlexNetwork с помощью HP Technology Services. HP предлагает услуги по миграции от проприетарных сетевых протоколов, например Cisco EIGRP (хотя в Cisco этот протокол называют «открытым стандартом»), к действительно стандартным протоколам маршрутизации OSPF v2 и v3. Кроме того, HP предлагает сервисы администрирования FlexManagement и набор услуг, касающихся жизненного цикла каждого модульного «строительного блока» HP FlexNetwork, включая планирование, проектирование, внедрение и сопровождение корпоративных сетей.

HP продолжает улучшать возможности своего оборудования, как на уровне аппаратных платформ, так и на основе концепции Software Defined Network (SDN), внедряя различные протоколы динамического управления коммутаторами и маршрутизаторами (OpenFlow, NETCONF, OVSDB). Для построения масштабируемых Ethernet фабрик в ряде моделей сетевых устройств HP внедрены такие технологии как TRILL, SPB, VXLAN (перечень устройств с поддержкой этих протоколов постоянно расширяется). В дополнение к стандартным протоколам категории DCB (в частности VPLS), HP разработаны и активно развиваются фирменные технологии эффективного объединения географически распределенных ЦОД в единую L2 сеть. Например, текущая реализация протокола HP EVI (Ethernet Virtual Interconnect) позволяет подобным образом объединить до 64-площадок ЦОД. Совместное же использование HP EVI и протокола виртуализации устройств HP MDC (Multitenant Device Context) предоставляет дополнительные возможности по расширению, повышение надежности и безопасности распределенных виртуализированных L2 сетей.

Выводы

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

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

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

Наши предыдущие публикации:

» Внедрение MSA в виртуализированном окружении предприятия
» Дисковые массивы HP MSA как основа для консолидации данных
» Мультивендорная корпоративная сеть: мифы и реальность
» Доступные модели серверов HP ProLiant (10 и 100 серия)
» Конвергенция на базе HP Networking. Часть 1
» HP ProLiant ML350 Gen9 — сервер с безумной расширяемостью

Спасибо за внимание, готовы ответить на ваши вопросы в комментариях.

ссылка на оригинал статьи http://habrahabr.ru/post/254645/

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

1. Пребывающая у всех на слуху политика импортозамещения, внедряемая правительством;
2. Популяризация PostgreSQL силами энтузиастов и развитие российского сообщества благодаря таким мероприятиям как PG Day и PGConf;
3. Расширение функциональных возможностей PostgreSQL, позволяющих разработчикам строить гибкие и «schema-less» приложения, не теряя при этом всех преимуществ СУБД, таких как честные транзакции, отказоустойчивость, возможности масштабирования и др.

Нам удалось убедиться в эффективности PostgreSQL несколько лет назад. Внедрение СУБД позволило ликвидировать серьезный технологический кризис на одном из крупных проектов компании. Подробный рассказ об этой success story состоялся на PG Day’14 Russia, прошедшем в прошлом году в Санкт-Петербурге. С тех пор нам довелось попробовать базу данных для решения широкого спектра проблем.

За четыре года мы провели около 15 миграций с различных хранилищ на проектах разной степени критичности и нагруженности, от мелких сервисов до крупных баз, набирающих до терабайта транзакционных логов ежесуточно. Сегодня около 85-90% задач по хранению и обработке данных разного профиля в проектах нашей компании решается средствами PostgreSQL.

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

Что такое «миграция»?

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

Прежде чем бросаться переписывать код, надо взвесить все «за» и «против» и удостовериться, что мигрировать базу все-таки надо. Частенько, принимающие решение о миграции лица неадекватно оценивают необходимость смены базы данных, руководствуясь необъективными критериями. Нередко выясняется, что добиться приемлимого результата можно на уже имеющейся базе данных, хорошенько ее изучив и попробовав разные варианты. Если вы еще этого не сделали, забудьте про миграцию. «Съезжать» с неизученной базы — неоправданно высокий риск. Неизведанные подводные камни не раз и не два всплывут в процессе работы, порождая неучтенные зависимости, задержки в сроках и общее недовольство.

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

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

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

С чего начать миграцию?

Миграция — это перенос данных в новое хранилище. Логично предположить, что начинать надо с оценки состояния текущего хранилища. Изучить схему, оценить её запутанность. Сколько таблиц в ней хранится, какие на них определены индексы, триггеры, внешние ключи. Каковы объемы данных, которые хранятся в этих таблицах? Есть ли какой-то код, который располагается внутри хранилища (хранимые процедуры и подобные вещи)? Какие компоненты и сервисы вашей системы работают с базой? Какой код приложения взаимодействует с базой?

Ответы на указанные вопросы позволят понять несколько важных вещей.

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

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

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

Допустим, вы хотите смигрировать базу с MySQL на PostgreSQL, и для разбиения задачи на части намереваетесь сделать PostgreSQL slave-узлом «мускуля». Прием вполне осуществимый и на поверку кажущийся нехитрым: включить репликацию, «парсить» бинарный лог самодельным скриптом, преобразовывать SQL-инструкции в PostgreSQL-совместимый формат и засовывать в целевую базу. На практике, это обернется кошмаром и адскими муками. Каждая приходящая на телефон «смска» будет заставлять вас нервно вздрагивать и ожидать, что пришел “привет” от сломавшегося скрипта, которому не удалось разобрать очередной пришедший запрос.

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

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

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

Переработка схемы и данных

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

Не ленитесь, пройдитесь по схеме, поищите вхождения в коде и устраните все лишнее. Аналогичной экзекуции необходимо предать все данные, которые не нужны для функционирования сервиса. В любой системы есть миллионы и гигабайты статистики “за все время”, которые жизненно необходимы для коммерческого отдела, но на практике изымаются на свет Божий от силы пару раз за год. Терабайты архивных логов, о которых так увлекательно коллеги рассказывают на конференциях. Все это надо безжалостно извести из базы данных. Если кто-то будет сопротивляться, аргументируйте это снижением затрат времени на миграцию вообще и перенос данных в частности. Меньше данных — быстрее перекинем их в новую базу и запустим сервис. Математика простая.

Теперь пора подумать над адаптацией схемы данных. Сразу же огорчу, автоматизировать этот процесс невозможно и, в общем-то, не нужно. Не тратьте временя на поиск инструмента, который автоматически сконвертирует вашу схему. То, что вы получите на выходе, с первого раза не заведется, и вы потратите кучу времени на “допиливание” результатов труда такой программы. Схема данных функционирующего продукта — явление слишком сложное и четкой формализации не поддающееся. Любая сторонняя утилита выдаст некоторую аппроксимацию того, “как быть должно”, и абсолютно проигнорирует большинство тонкостей вашей конкретной системы.

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

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

Со схемой разобрались, пора мигрировать данные. Тут вся история выглядит ровно аналогичным образом. Забудьте про автоматизацию и универсальные решения. Пишите на коленке нехитрый скрипт, который выгрузит данные из исходного хранилища и импортирует в целевое. В нашей практике, наиболее эффективным способом это сделать оказался банальный “дамп” табличек в формате CSV. Все более-менее адекватные базы позволяют сделать такой “дампик”, сконфигурировав некоторое количество параметров (символ экранирования, разделитель, перенос строки, символ NULL и т.д.). Файлики получаются сравнительно небольшие, аккуратные, хорошо сжимаются gzip-ом для последующей передачи по сети (опять же, банальным rsync-ом) и очень быстро кушаются PostgreSQL (хинт: используйте COPY).

Сделать скрипт — вопрос одного вечера. Особая прелесть такого инструмента заключается в том, что вы легко можете запрограммировать в него обработку любых специфических ситуаций. Не стесняйтесь, “хардкодьте”. Если в какой-то табличке умудрились сохранить “копипасту” из Microsoft Word со спецсимволами, пройдитесь по файлику с помощью perl/sed или чего-нибудь еще, откорректируйте и сложите на импорт. В общем-то, такой подход — единственный, который позволит избежать неожиданностей и гарантировать полный перенос всей базы данных. Аналогичным образом подготовьте скрипты, которые импортируют какие-то дополнительные объекты, например, значения sequences для соответствующих колонок.

Как только инструменты сделаны и достигнут успешный экспорт-импорт данных, необходимо организовать автоматизированную проверку всего этого хозяйства. Представьте, что это backup & recovery решение. Любой уважащий себя инженер знает, что недостаточно только лишь штатно “снимать” резервную копию. Ее надо так же штатно проверять, поскольку “бекап” имеет обыкновение ломаться, чего лучше не допускать. Поступайте аналогично. Раз в неделю осуществляйте автоматизированный (или ручной, кому как удобнее) прогон экспорта-импорта со свежими данными из “боевой” базы. Работать над подготовкой к миграции еще предстоит очень долго и, с большой долей вероятности, в базе за это время произойдут какие-то изменения или появятся данные, которые вы не учли. Чтобы не бороться с этими сюрпризами в боевых условиях во время реальной миграции, своевременно выявляйте проблемы и решайте их.

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

Переработка кода

Адаптация кода приложения — самая неизбежная и печальная часть всего меропирятия. Прежде чем начинать, надо определиться с некоторыми важными моментами.

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

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

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

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

Теперь можно открывать текстовый редактор и приступать к переработке кода. Насколько это окажется сложным и сколько времени займет, никто вам сказать не может. Ваш код, вам виднее. Возможно, вам повезет и у вас не будет трехэтажных SQL-запросов в каждом модуле, во всю использующих database-specific “фичи” языка. К слову, я считаю, что это один из немного сценариев, где использование ORM для исполнения CRUD-запросов сильно объективно ускоряет разработку и упрощает жизнь программиста, а не наоборот.

Про тестирование

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

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

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

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

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

Тестируйте много и часто, делайте несколько подходов к уже ранее проверенному. Будут всплывать новые и новые изъяны. Не жалейте сил и времени. Чем меньше проблем потом всплывет в “продакшене”, тем успешнее будет результат работы, что приведет к категорическому одобрению со стороны руководства и поспособствует воспитанию трудовой дисциплины в вашем коллективе.

Про обучение

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

Безусловно, одних лишь правил разработки и прочих “гайдлайнов” мало. Чтобы коллеги оценили ваши усилия, коллектив надо обучать. Моя многолетняя практика показала, что обучение программиста — процесс сугубо индивидуальный, вне зависимости от того, какой задачей человек занимается, будь то миграция или стандартная ежедневная рутина разработки. Хотите получить компетентного специалиста? Извольте потратить время.

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

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

Запуск проекта после миграции — это своего рода новая жизнь для продукта. Как сказал недавно один мой коллега, никогда не удавалось застать тот момент, когда очередной проект перещелкивается из состояния «Сразу Сделать Все Правильно» в состояние «Изначально Все Было Сделано Неправильно». Тем не менее, все соучастники будут решительно настроены на то, чтобы в этот раз сделать лучше. Воспользуйтесь моментом и направьте энергию своих соратников в действительно нужное русло.

Час Ч

Непосредственно процедура миграции — задача не менее сложная и ответственная, чем все то, что ей предшествовало. К ее выполнению тоже надо подготовиться.

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

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

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

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

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

Планируйте миграцию на утро понедельника. Все должны быть отдохнувшие и выспавшиеся. Запретите накануне злоупотреблять спиртными напитками и иными веществами, “рубиться” всю ночь в MMORPG. Не давайте ставить на рабочие станции обновления ПО и ОС, пересобирать ядро линукса. Убедитесь, что не будет проблем с доступом в Интернет, организуйте резервную опцию, на случай поломки основного соединения. Подумайте о других возможных обстоятельствах, которые могут вам помешать.

Светлое будущее?

Как понять что миграция прошла успешно? Однозначно это станет известно только лишь спустя некоторое время. Но несколько более-менее объективных критериев выделить не помешает.

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

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

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

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

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

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

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

Одна из причин, по которой сообщество с возрастающей регулярностью выбирает эту СУБД для своих задач, это осознание, что PostgreSQL уже достаточно давно используется для решения потребностей крупного бизнеса. Даже представители промышленного и банковского сектора (областей, в которых традиционно правят балом коммерческие СУБД) не боятся применять бесплатную и открытую технологию. Ярким примером является крупнейший бразильский банк Caixa. Весь процессинг банковских карт в банкоматах страны построен с использованием PostgreSQL. Крайне интересный business case был описан одним из архитекторов системы на канадском PGCon’e в 2010 году. Мы решили пригласить коллегу из далекой Бразилии поделиться секретами успеха  на предстоящий питерский PG Day.

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

ссылка на оригинал статьи http://habrahabr.ru/post/254667/