Виртуальный дата-центр КРОК

Инфраструктура хранения данных современного предприятия отражает историю развития бизнеса и индустрии и зачастую разнородна: проприетарные системы хранения и обработки данных, кэширующие системы, системы хранения данных для Интернет-сервисов. Всё большее проникновение цифровых технологий в бизнес бросает вызов существующей IТ-инфраструктуре. Для сохранения имеющихся позиций на рынке необходимо обрабатывать всё большие объёмы всё быстрее меняющихся данных. Проприетарные решения не отвечают этому вызову не только в технологической, но и в экономической составляющей: лицензионная политика, общая стоимость владения часто линейно зависят от объёма обрабатываемых данных, что является недопустимым в условиях шквального роста цифровой составляющей бизнеса. Облачные решения недостаточно сформировались, с одной стороны, и ограничены в применении, с другой, особенно если речь идёт об обработке персональных данных, либо данных, имеющих жизненно важное значение для бизнеса. Единственным возможным на сегодняшний день ответом на вызов digital трансформации является внедрение решений с открытым исходным кодом. В данном докладе будет изложен опыт такого внедрения в крупную компанию телекоммуникационной индустрии. Речь пойдёт о построении платформы виртуализации данных на основе решения Tarantool. Преимуществами подхода виртуализации данных являются: - безболезненная интеграция с существующей IТ-инфраструктурой, платформа может выступать в качестве высокопроизводительного "фасада" к существующим источникам данных; - чрезвычайно высокая скорость работы с данными; - возможность работать с данными, а не с ис

Как партнер Макс Саппорт строил гибридное облако для клиента на платформе Облакотека, как оно работает, все технические и коммерческие подробности.

В последнее время сайты и веб-приложения растут всё быстрее, а задачи, стоящие перед БД, эволюционируют. Поэтому для (успешных) проектов традиционная реляционная СУБД часто не может удовлетворить все нужды. В ответ на эту проблему возникло большое количество разнообразных решений, очень различающихся по функциональности и характеристикам. При этом они все заносятся под один большой зонтик "NoSQL", что не способствует пониманию вещей. Запутанные веб-разработчики пытаются взять текущую модную и обсуждаемую NoSQL БД и приспособить её под свои нужды, не всегда понимая, нужную ли технологию они выбрали (референс к MongoDB is Web Scale http://www.youtube.com/watch?v=b2F-DItXtZs). Целью доклада является упорядочение хаоса в головах разработчиков. - Обзор популярных БД и их классификация (KV store, document store, columnar, etc). - CAP-теорема и её применение к выбору БД (где-то параметры можно настроить, где-то подпереть сбоку костылем, где-то - увы). - Типичные примеры применения. - Антипаттерны применения (из личного опыта и тысяч прочитанных вопросов на stackoverflow :) ).

Оптимизация любого веб-приложения — это нетривиальная задача, для решения которой требуется проводить мониторинг загрузки системных ресурсов, выполнять микро-вэнчмаркинг, экспериментировать с настройками, проводить нагрузочное тестирование и т.д. В текущем году нашей команде довелось поучаствовать в нескольких проектах, в которых перед нами стояла задача оптимизации J2EE веб-приложений. Один из них — портал для ОАО «Сбербанк России» (www.sberbank.ru). Основной сайт Сбербанка реализован на основе портального движка BackBase и является J2EE-приложением. При проведении оптимизации его работы нам пришлось изучить и собрать много информации и документов, которые связаны с настройкой и оптимизацией высоконагруженных веб-приложений. В ходе реализации проектов я заметил, что не существует сводного документа с инструкциями по оптимизации работы приложения, поэтому решил поделиться нашим опытом. Этот доклад может послужить в качестве дорожной карты (Road Map) для настройки и оптимизации J2EE веб-приложений. В докладе будут рассмотрены следующие аспекты: 1) Общие подходы и методология оптимизации веб-приложения. 2) Оптимизация настроек веб-сервера. 3) Оптимизация кода приложения на стороне клиента. 4) Оптимизация на стороне middleware, в том числе на сервере приложений. 5) Оптимизация на уровне Базы Данных.

Highload++ 2013

- как ошибка выбора идентификатора пользователя, обнаруженная после запуска проекта, чуть не стоила 2 лет разработки - как мы боролись с перегруженным mysql когда даже включение binlog убивает сервер - почистил партицию mysql под нагрузкой - получи мертвый сервер - как верстальщик поменял верстку серча и уложил продукт на 4 часа - ошибка в ядре php которая привела даунтайм на несколько часов - как незнание особенностей работы GC у redis обошлось в $50к чистой прибыли - добавлением или удалением серверов из пула memcached инвалидировали весь кэш (кривые настройки php клиента Memcache/Memcached) - как поправив тест потерять 2 миллиона пользовательских писем - как релиз одного проекта крэшил хелсчеки соседнего проекта - самый большой фейл с системами очередей и статистикой: ивенты терялись годами

Первая часть. Концепция облачного ИТ-аутсорсера. Вторая часть. Детальный разбор кейса размещения облачной ИТ на платформе Облакотеки со всеми цифрами и техническими решениями. Партнер - Макс Саппорт

На примере платформы SAP HANA рассмотрим подходы к созданию высокопроизводительной платформы для управления большими массивами данных и выполнения сложных вычислений. В ходе сессии будут представлены архитектурные решения, которые частично легли в основу платформы, а также будет проведён сравнительный анализ предложенных решений в приложении к современным разработкам Intel в области архитектуры ЭВМ. Тезисы - http://www.highload.ru/2015/abstracts/1856.html

Информация о компании СетьПроект - краткий обзор

Расскажу, какие подходы и инструменты практически применяются в Wargaming при обработке данных в гигантской, без преувеличений, системе. Частичный список затрагиваемых вопросов NoSQL versus/with RDBMS или каждый инструмент на своем месте Синхронные и асинхронные подходы к построению систем: почему асинхронные системы не могут быть быстрее синхронных, но асинхронность, тем не менее, очень полезна API и интерфейсы — важная составляющая хорошо спроектированной системы Performance vs Scalability Мониторинг и профилирование

Различные примеры использования внешних облаков для различного размера бизнесов.

1. Вводная часть: базовые понятия и определения 1.1. Что такое “файл” 1.2. Роль файлов в современном мире, миф о ненужности файлов 1.3. Файловое хранилище АКА файловая система 1.3.1. внутреннее устройство 1.3.1.1. винтажные и журналируемые. зачем нужен журнал 1.3.1.2. плоские и иерархические 1.3.1.3. контроль доступа 1.3.2. POSIX 1.3.2.1. произвольное чтение 1.3.2.2. произвольная запись 1.3.2.3. атомарные операции 1.3.3. bells and whistles 1.3.3.1. сжатие, шифрование, дедупликация 1.3.3.2. snapshots 1.4. кеширование чтения и записи 2. HighLoad - это сеть 2.1. что вообще такое “HighLoad”, или “ведет ли кроилово к попадалову” 2.2. протоколы доступа: stateless и stateful 2.3. отказоустойчивость и ее двуличие 2.3.1. целостность данных 2.3.2. бесперебойные запись и чтение 2.4. Теорема CAP 3. Так в чем проблема? 3.1. Берем большую-пребольшую СХД и… 3.1.1. локальный кеш?! 3.1.2. конкурентная запись?!! 3.1.3. Берем OCFS2 и… 3.1.3.1. Как “падают виртуалки”?! 3.1.3.2. И почему так медленно? 3.1.4. А еще большую-пребольшую СХД довольно трудно получить в свое распоряжение 3.2. Берем CEPH/Lustre/LeoFS и… 3.2.1. Почему так медленно?! 3.2.2. Что значит “ребалансинг”?! 3.3. И немного о резервном копировании 3.3.1. Резервное копирование - это не отказоустойчивость 3.4. И снова про атомарные операции 3.5. Так почему все-таки нельзя просто сложить файлы в базу? 4. Что же делать? 4.1. В первую очередь это зависит от того, какова наша задача 4.1.1. А надо ли экономить? 4.1.2. POSIX - нужен ли он? 4.1.3. Большие файлы - нужны ли они? 4.1.4. Атомарные операции - нужны ли они? 4.1.5. Версионирование - нужно ли версионирование? 4.1.6. Насколько большим должно быть наше хранилище? 4.1.7. И собираемся ли мы удалять файлы? 4.1.8. И каков будет профиль нагрузки? 4.2. I’m feeling lucky - для некоторых сочет�