Случайны выбор дневника Раскрыть/свернуть полный список возможностей


Найдено 116 сообщений
Cообщения с меткой

хостинг-провайдер - Самое интересное в блогах

Следующие 30  »
rss_rss_hh_new

Гипер-конвергентное решение – FusionCube и FusionSphere Openstack для провайдера облачной услуги

Понедельник, 11 Июля 2016 г. 18:40 (ссылка)





Продолжаем публиковать материалы форума Облачные технологии в России, который наша компания вместе с технологическим партнером HUAWEI провели 23 июня в LOTTE HOTEL MOSCOW. Первые три части вы можете прочитать здесь: часть I, часть II, часть III. Сегодня представляем читателям интересный доклад Дениса Дубинина на тему современных инструментов создания облачных решений.











Денис Дубинин, менеджер по продуктам ИТ, сервера, СХД, виртуализация, HUAWEI



Добрый день! Зовут меня Денис Дубинин, я продакт-менеджер компании HUAWEI по продуктам, серверам СХД и системам виртуализации. Сегодняшняя тема моего доклада называется FusionCube, FusionSphere, инструменты для создания облаков. Кто-нибудь пользовался уже нашим ПО, облачным, скажем так, направлением? FusionSphere, какими-то другими вещами? FusionStorage? То есть вообще никто не сталкивался? Ну сегодня попытаюсь приоткрыть тайну, висящую над этими продуктами, что же они из себя представляют. Начну я сейчас с решения FusionCube, что это такое.







Пару слов о компании HUAWEI. Компания HUAWEI — международный лидер по производству телеком-оборудования для различных операторов связи — сотовой связи, фиксированной связи, магистральных каких-то линий. Вот слышал, тут сегодня были разговоры про оптику Владивосток, Сахалин и прочее, прочее. Собственно, этими вопросами тоже HUAWEI занимается. В принципе, здесь коротко наше портфолио, чем же занимается HUAWEI в направлении энтерпрайз — облачные решения, про которые мы сегодня поговорим, серверы, системы хранения данных, сетевое оборудование, достаточно широкого профиля от, еще раз, магистральной оптики, заканчивая вай-фаем, коммутаторами для центра обработки данных, стандартных кампусных решений. Есть решения по сетевой безопасности, анти-DDOS решения, антивирусные файерволы и прочее, прочее, прочее…спектры трафика и так далее. И инженерная инфраструктура для ЦОД, т.е. HUAWEI также производит бесперебойные источники питания, кондиционеры, модульные ЦОДы, контейнерные ЦОДы и все, что с этим связано.







Про решение FusionCube, что же это такое. FusionCube – это гиперконвергентное решение, которое, скажем так, позволяет заказчику сэкономить время, сэкономить ресурсы для того, чтобы развернуть IT-ландшафт для какой-то своей задачи. Почему не просто конвергентное, а именно гиперконвергентное – потому что в едином корпусе, в едином шасси все три компонента, собственно, сервера, сетевое оборудование и система хранения данных. Причем, система хранения данных это не отдельные аппаратные выделенные элементы, а для системы хранения данных используются ресурсы самих серверов, т.е. устанавливается определенный софт, получаем software defined storage, и этот software defined storage презентуем собственно сереверам, которые вращаются на этой же аппаратной платформе. В текущий момент у нас, скажем так, две модели – FusionCube 9000 и FusionCube 6000.







Параметры их здесь приблизительно видны. Значит, старшая модель позволяет в одном шасси получить до 32 процессоров, 12 терабайт оперативной памяти, 172 терабайта под систему хранения данных. FusionCube 6000 – решение полегче, попроще, поменьше – здесь до 8 процессоров, до 2 терабайт оперативной памяти на такой модуль и до 280 терабайт хранения. В принципе, тут уже указаны для младшей модели общие направления, для чего стоит применять, скажем, вот это решение, то есть до виртуализации 60 каких-то серверов, до 280 рабочих мест виртуализированных. Если вам нужно больше параметры, то, наверное, стоит уже рассматривать решение 9000-е.







По поводу применения FusionCube. FusionCube — это не равно облако. FusionCube — это не равно виртуализация. FusionCube, скажем так, это равно некая универсальная структура, некий универсальный IT-ландшафт, который вы вольны распределять, использовать на свое усмотрение.

Для 9000-х систем существуют уже апплайенсы протестированные, готовые, сертифицированные для решений с УБД, баз данных, такие как SAP HANA, ORACLE и прочие. Есть решения гибридные, когда часть нод используется под виртуализацию, часть НОД используется под базы данных, допустим, часть нод используется для узлов SAP HANA.

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







По поводу, из чего же состоит FusionCube и почему мы FusionCube называем определенный набор решений, а не просто любой наш сервер обзываем FusionCube. По решениям, первое – конвергентное. В этом решении отсутствует выделенное СХД. Если мы поставили несколько серверов в один ряд, прикрепили к ним СХД аппаратную, то это уже не FusionCube. Это просто какой-то кластер. Упрощенно, управление вот этим FusionCube происходит из одного окна, то есть менеджмент и управление аппаратным железом, софтверными вещами, которые на нем установлены, производится из одной консоли операторской. Ну и решение достаточно мощное, потому что используется, опять же, распределенное СХД и ряд элементов, которые повышают производительность. Это передача данных по InfiniBand и использование наших SSD PCI-экспрессных карт для хранения данных и для кэширования данных.







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







Про сравнение с классической архитектурой, преимущества: меньше занимает места в несколько раз, энергоэффективность, зеленые технологии и так далее.







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







По поводу быстрого развертывания – для тех, скажем так, протестированных сценариев, которые предлагаем мы с использованием FusionCube, уже готовые есть инструменты, которые позволяют быстро развернуть этот FusionCube под конкретную задачу. Есть ПО, называет FusionCube Builder – это installation tool, т.е. вы его запускаете на своем лэптопе, по сети подключаете к FusionCube, как в визарде делаете – next, next, next, в итоге получаете тот ландшафт, который вы заказывали. И FusionCube Center – это, собственно, менеджмент платформа, которая позволяет интегрировано этим всем, ну не скажу чтобы до конца управлять, но, по крайне мере, мониторить точно на 100%.







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







Из преимуществ, про software defined storage будет еще дальше рассказано, но собственно, чем оно отличается от классической архитектуры. В классической СХД присутствуют – сеть передачи данных, san сеть, либо 10 Гбит, либо 8 Гбит файбер ченнел, либо 16 Гбит файбер ченнел, дальше стоит контроллер, в классических системах 2-контроллерные машины, сейчас идет развитие мульти-контроллерных систем, но, как правило, количество контроллеров в СХД ограничено. Я, допустим, не знаю ни одной СХД, в которой контроллеров больше восьми. Скажем так, можем повысить эту цифру – больше 16 контроллеров точно нет у СХД. И, собственно, количество дисков, которое может обслужить этот контроллер. Мы все при использовании классической архитектуры СХД можем в любой момент времени упереться в один из этих ограничивающих факторов. Либо san сеть у нас начинает тормозить, не хватает производительности, либо контроллер в СХД, имеющийся, начинает тормозить, не хватает производительности, либо количество дисков – мы дошли до того предела, что дальше диски ставить просто некуда. От всех этих проблем на избавляет, собственно, распределенное хранилище, где каждый сервер, во-первых, является узлом хранения, поэтому при увеличении нагрузки у вас, естественно, растет количество серверов, которое должно переваривать эту нагрузку и автоматически растет количество узлов в виртуальной СХД. Таким образом, мы избавляемся от узкого места по поводу жестких дисков. Больше серверов, больше дисков, если нужно еще больше дисков, мы просто добавляем сервера в нашу инфраструктуру, практически ничем не ограничены.

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







Вернусь немножко назад, я говорил, что Fusion Cube – это не значит облако, даже частное, это не значит 100% виртуализация, это значит – какой-то универсальный IT-ландшафт, причем он уже может быть протестирован и существовать рекомендации, сертификации, о том, как этот ландшафт использовать. Вы его можете использовать под Oracle, под IBM DB2, Sybase, под решения SAP HANA, если с такими работаете, под FusionSphere, опять же приложениями sub и под, в принципе, просто виртуализацию на базе VmWare, в принципе можно использовать и с нашей FusionSphere, надо было добавить, наверное, еще седьмую строчку, как бы самый очевидный вариант.







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



Почему он не является узким местом для нашего решения – потому что мы не храним метаданные в явном виде, мы храним только хэш-суммы, т.е. когда сервер отсылает запрос за каким-то блоком данных, он не отсылает его в явном виде, т.е. блок такой-то, цилиндр такой-то файл такой-то и т.д., встроенный драйвер, который инсталлирован в систему, высчитывает хэш-сумму от данного запроса и отправляет в сторону нашей виртуальной СХД только вот этот вот запрос, состоящий из хэш-суммы. Запрос этот минимальный, в принципе, объем хэш-таблицы у нас 232, я не знаю сколько это миллиардов, олимпиардов является в десятичном виде, и, в принципе, вся эта таблица занимает 6Мбайт, и каждый узел, участвующий в системе хранения данных, хранит копию вот этой таблицы. Она у нас называется, правда, не таблица, а кольцо, но смысл, что это функционально, что это таблица. То есть весь этот объем 6Мбайт всегда хранится у узла в оперативной памяти, даже скажу больше, он часто хранится в кэше процессора, т.е. в самом быстродействующем месте, и, в принципе, он распределен равномерно между всеми узлами, которые участвуют в хранении. Поэтому за счет этого обращения по хэш-сумме, т.е. сервер обращается «где мои данные», драйвер обрабатывает запрос, говорит «вот по адресу этого хэша», хэш отсылается к хранилке, хранилка обрабатывает этот кэш, говорит «вот этому хэшу соответствует вот тот-то узел хранения», приходит запрос на узел хранения, и уже вот это запрос разбирает узел хранения и он уже знает, где у него что лежит по полочкам. То есть за счет вот этого уменьшения передаваемых данных по адресации и распараллеливание этих запросов, что можно хэш-сумму высчитывать параллельно на нескольких машинах и так далее, и так далее, получается более высокая производительность.







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







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







Про алгоритм ребалансировки — казалось бы, очевидная вещь, но почему-то мне часто задают вопрос: «а если вот у нас было 10 узлов в системе хранения, мы добавили еще 20 узлов, перераспределение это для повышения производительности будет происходить?» Да, повышение перераспределения данных по узам происходить будет, собственно, ради этого все и затеялось. Есть отдельный механизм, который занимается этим вопросом.







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







По поводу восстановления данных – за счет того, что отсутствует единый контроллер, через который происходит восстановление, за счет того, что данные все распределены между узлами, как правило, равномерно более менее, процесс ребилдинга в данных системах достаточно быстр, т.е. вам не нужно ждать, вот внизу приведены примеры, за 30 минут ребилдится один терабайт данных, т.е. если у вас рухнул сервак, на котором у вас лежало 4Тбайт данных, то система вернется в исходное устойчивое состояние меньше, чем за два часа. Если вспомнить классические СХД, то они могут неделями восстанавливаться после падения 4-терабайтных систем, 4-терабайтных дисков. Собственно, показывается, демонстрируется, как происходит ребилд. В принципе, ничего космического, непонятного, странного, все то же самое, просто идет это в несколько потоков, параллельно, поэтому этот процесс идет значительно быстрее.







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







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

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







По поводу аппаратной части, из чего же состоят наши FusionCube, что это такое: собственно, 9000-й состоит из нашего блейд-шасси, собственно вот сама корзина, вид спереди, можно поставить 16 половинчатых серверов, либо 8 4-процессорных серверов, либо серверов с системами хранения с жесткими дисками, не системами хранения данных еще раз, с обратной стороны – блоки питания, вентиляция, сетевой интерконнект и модули управления самим шасси, через которые происходит управление аппаратными узлами этого агрегата.







Так, по узлам – это не все узлы, которые у нас есть для наших блейдов, их список значительно шире, больше, есть специфические модели, компактные, когда в один слот вставляется два двух-процессорных сервера, скажем так, популярное решение для high performance компьютинга. Но вот самая типовая набивка именно для FusionCube – двух-процессорный сервер, 24 планки памяти, 2 процессора Xeon Е5, в принципе, поколение Е4, E3 доступно, сервер 222-й в правой части, он аналогичен вот этому серверу, просто у него есть пристежная корзина на 15 жестких дисков, это вот узел хранения, который будет использоваться в Fusion Storage. Здесь есть выделенный RAID контроллер аппаратный от LSI, но как правило, он используется в режиме рейда первого, нулевого, когда все диски доступны индивидуально. Скажу сейчас, что в следующем месяце появляется новый узел, в котором, правда, не 15 дисков, а 12 дисков, и они уже подключены по протоколу NVМe, т.е. они через PCI-express подключаются с минимальными задержками, латентностями и так далее. Есть еще 226-й узел под 3-дюймовые диски, т.е. если нужен узел для медленного хранения 8-10 терабайтников, то он тоже есть для блейдов. 220-я модель –блейд сервера c 6-ю pci-ными слотами, внутрь можно поставить PCI-карточки обычные, причем, две из них можно выкинуть порты наружу, в них включить либо специфические карточки сетевые, которые пробрасывают трафик через себя в выключенном состоянии, либо NVIDIA Cuda поставить, как они там, Intel Fixion и прочие специфические вещи. Из особенностей, кстати, попрошу прощения, вернусь к 121-му узлу – туда можно поставить внутрь блейд-сервера одну PCI-экспрессную карту, обычную с лезвийным разъемом, т.е. не мезонинный, не какой-то проприетарного протокола, а обычного, обычный PCI-express, это может быть наша SSD-шная карточка, это может быть, я не знаю, ключи для 1С юсбишные, это может быть какая-то криптография кастовая, это может быть ограничение доступа к серверу и так далее, т.е. в обычный узел двух-процессорный можно смонтировать такую карту. Ну и, собственно, 242 узел – это 4-процессорник, 1 Тбайт оперативной памяти, 4 процессора Xeon Е7.

Сетевая коммутация, которая используется в FusionCube. 310-й – это 10-гигабитный коммутатор, CX611 – это InfiniBand коммутатор. В принципе, у нас сейчас доступны 40-гигабитные коммутаторы уже как год, даже больше, уже второй год, как доступны для блейдов 40Гбит и в сентябре будет доступен 100Гбит InfiniBand, т.е. если вы боитесь, что упретесь в производительность сетевого интерконнекта, можете не бояться, еще очень нескоро в него упретесь.







Младшее решение FusionCube 6000, здесь, кстати, ошибка, ну не ошибка, а цветом подсветили неправильно, 6000-я – 4-юнитное шасси, в которое можно поставить до 8 процессорных серверов. Здесь изображено 4 узла, покажу, что дальше за узлы… Сетевой интерконнект доступен с лицевой части, сзади 4 блока питания общие, которые питают всю конструкцию, и система охлаждения, которая также охлаждает всю конструкцию. Сзади есть pci-слоты, которые проброшены прям по каждому серверу в эти сектора.







Про сервер – сервер, опять же, есть в достаточном ассортименте, есть сервера с жесткими дисками, подключаемые по sas-протоколу, есть по pnvme-протоколу, есть, вот здесь изображено, два процессора и 12 трех-дюймовых жестких диска, а внутри салазок трех-дюймовых могут стоять двух-дюймовые жесткие диски. Есть вариант с подключением по sas, есть вариант по NVМe, есть вариант с PCI-express, т.е. стоят pci-экспрессные разъемы, туда можно поставить либо видеокарты NVIDIA Cuda и прочее, либо, допустим, наши PCI-экспрессные карты.







Ну и, собственно, наши PCI-экспрессные карты – внезапно, скажем так, историческая справка: компания HUAWEI является той компанией, которая первая выпустила вот эти вот карты вообще в мире, т.е. они существуют сейчас у многих вендоров, в широком ассортименте, какие-то карты лучше наших, скажем так, больше нравятся заказчикам, какие-то карты мы считаем, что лучше, чем другие, но тем не менее, вот этим вот вопросом, создание PCI-экспрессных SSD-карт HUAWEI начал заниматься достаточно давно и выпустил в промышленную эксплуатацию эти карты одними из первых. Это SSD накопитель, который втыкается в PCI-ный разъем, за счет отсутствия этих sas-протоколов, за счет отсутствия sas-овских RAID контроллеров и пр. его латентность 9 микросекунд, не миллисекунд, а микросекунд, то что, в общем-то, на 1000 порядков меньше, чем параметры классических СХД или классических жестких дисков. Параметры по производительности по IOPS-ам, собственно видите, 770 в пике и до 230 в стабильном режиме. В общем-то инсталляция этих карточек внутрь узлов хранения позволяет нам не беспокоиться о производительность нашей софтверной СХД. Несмотря на то, что там могут использоваться обычные SAS-диски, SATA-шные диски, при наличии вот этих вот карточек, за счет кэширования данных на них, производительность достаточно велика.







По поводу управления – в принципе, я уже коротко сказал, есть FusionCube Builder, ставите на лэптоп, подключаете FusionCube, делаете next, next, next, к сожалению, слайд на китайском языке. Сразу скажу, это доступно для ограниченного набора ПО, т.е. вы не можете там…визарда для создания лотус нотуса нет, или для 1С, к сожалению, нет пока. Есть для ландшафта FusionSphere или для ландшафта Vmware ESXi. Делаете next, next, next, за один час разворачиваете до 8 узлов, собственно, готовых, сконфигурированных.







Затем мониторинг. Мониторите сразу через единое окошко физические сервера, физические сетевые компоненты, Fusion Storage, хотел сказать физическую хранилку, но не физическую, а виртуальную и пулы ресурсов виртуальных машин, либо на данный момент доступна FusionSphere и VmWare продукт.







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

Повожу небольшое резюме: FusionCube это аппаратное решение с виртуальной СХД, с software defined storage. Как вы будете использовать в дальнейшем FusionCube, в общем-то, зависит от ваших задач, которые вы собираетесь решать. Еще раз повторюсь, FusionCube это не равно виртуализация, да, это один из вариантов применения, но не обязательно 100%.







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







Компания HUAWEI участвует в данном мероприятии, вклад в OpenStack Community оценивается следующими параметрами: 23 новшества было привнесено компанией, 63 бага, вот красным цветом это показывает место, которое занимает HUAWEI по величине вклада, программного кода и т.д. В принципе, тут должна быть такая небольшая похвальба, что мы вот участвуем в OpenStack Community, у нас там статус золотой, в общем-то, мы с вами, из этой серии.







Все-таки из чего же состоит программный продукт, где заканчивается HUAWEI и начинается OpenStack. Собственно, вот про этого героя я вам уже все практически рассказал. FusionStorage является компонентом FusionSphere, но он может покупаться, приобретаться, использоваться отдельно.

Fusion Compute – это серверная виртуализация, это гипервизор и сервер, который управляет гипервизорами. У нас он называется Virtual Resource Manager или VRM сокращенно, это аналог VmWare-вского V-center. Вы через вот этот вот VRM управляете нашими гипервизорами, нашими виртуальными машинами и так далее. И, в том числе, есть там закладка для FusionStorage.

Следующий компонент – FusionNetwork. На данный момент он представляет, пока что уверенно можно говорить только про одну инстанцию – это виртуальный свитч, распределенный между гипервизорами, остальные элементы SDN-контроллеры, они пока что таким пунктиром выделены, т.е. они пока что в разработке и для коммерческого использования не доступны. Ключевое слово «для коммерческого». Далее через плагины, через драйвера, это дело интегрируется с контроллерами OpenStack, который сверху управляется, опять же, через наш портал управления, который называется ManageOne, т.е. в комплекте с нашим решением есть еще и портал самообслуживание и административный портал, они на одном сервере крутятся, просто под разные задачи. Здесь можно определить, где заканчивается HUAWEI и начинает OpenStack. Да, за развитие собственных гипервизоров, за развитие СХД, за развитие сети, отвечает компания HUAWEI. За интеграцию с OpenStack отвечают все вместе.









По поводу параметров FusionSphere, параметров виртуализации – хвалиться особо нечем, параметры на самом деле, такие же, как и у всех – 128 виртуальных процессоров на одну виртуальную машину, до 4 Тбайт оперативной памяти, 64 Тбайт максимальный размер жесткого диска, 60 дисков на одну виртуальную машину, 12 сетевых интерфейсов виртуальных на одну виртуалку, количество физических ядер на сервере до 480, оперативной памяти физической, на которой развернута Fusion сфера, до 12 Тбайт, одновременное количество включенных виртуальных машин 1000 на одном кластере. Эти параметры тоже озвучивать не буду, кому-то нравится, кому-то не нравится, в принципе, параметры средние по больнице, средние по отрасли, т.е. у Hyper-V или у ESXi Vmware примерно то же самое.







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







По поводу безопасности пользователей — для каждого пула ресурсов существует свой сисадмин, т.е. у нас нет единого супер-админа, супер-рута, который может настраивать сразу все, и физическое оборудование, и пулы ресурсов, и приложениями, и инфраструктурой виртуальной, нет, это 4 разные инстанции и они должны между собой согласовывать свои действия. В принципе, с вопросом безопасности сюда же отправляю вопрос по ФСТЭКу. В данный момент система находится в процессе обследования, соответственно одобрения, сертификат в ФСТЭК будет получен где-то в сентябре-октябре на данный продукт. Данный продукт на данный момент сертификацией не обладает.







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







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







Поддержка операционных систем гостевых – поддерживается достаточно широкий ассортимент, начиная с Windows-систем, заканчивая совершенно экзотическими внутри-китайскими, скажем так, линуксами, которые, в общем-то, никого не интересуют за пределами Поднебесной, но тем не менее, они также поддерживаются. Есть еще волшебный вот такой вот сегмент – кастом, т.е. если вам нужна интеграция с нашей Fusion сферой, вам нужны какие-то виртуальные драйвера, обращайтесь, если что наш R&D готов решить и эту задачу.







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

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







Отечественный заказчик – компания Антарес, специфический у него выбран сегмент бизнеса – это voice over lte, voice over wi-fi, то есть это сотовый оператор связи, но он пользуется либо lte, либо wi-fi для передачи голосового трафика, т.е. он не пользуется ни 2G, ни 3G сетями, как таковыми. Вот у них тоже ядро сети оператора сотовой связи полностью реализовано на нашем решении, в том числе на наших блейдах. В принципе, можно сказать, что это FusionCube с FusionSphere для реализации вот этих задач.







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







Еще внезапные потребители вот этого ПО – сама компания HUAWEI. Зачастую бывает, что компании, которые производят тот или иной продукт, ими стараются не пользоваться. Здесь ситуация обратная, все наше R&D сидит на VDI, на виртуальных рабочих столах, все эти виртуальные рабочие столы развернуты в облаке, т.е. у сотрудников нет ни ноутбуков, ни лэптопов никаких, ничего нет, они сидят полностью на этой облачной инфраструктуре. Я не говорю про продавцов, я не говорю про менеджеров, я говорю про R&D, про инженеров, которые занимаются разработкой.







И, собственно, наверное, самый интересный проект – это Deutsche Telecom, T Systems. К вопросу об импортозамещении и хранении личных данных это забава не наших правителей российских, это международная забава вообще. В Германии в один прекрасный момент поняли, что большинство их компаний китайских пользуются ресурсами Amazon, кому принадлежит Amazon – вопрос достаточно темный, он точно не подвластен немецкому правительству, вопрос, кому же он принадлежит, Ирландии или США, в какой юрисдикции находится, остается в воздухе. Этот момент не устроил немецкое правительство, и был выбран отечественный немецкий оператор, прошу прощения, не оператор, а телеком-компания Deutsche Telecom для реализации отечественного облака, чтобы оно находилось на территории Германии, чтобы там хранились все данные, которые принадлежат компаниям, юрисдикция которых попадает под немецкое законодательство, и, собственно, это работало отказо-устойчиво, безотказно, 24/7, с гибкими сервисами, и вообще это был немецкий Amazon, в общем-то, в двух словах. И этот вопрос был успешно закрыт компанией HUAWEI в 2016 году на CeBIT была презентация этого решения, что оно теперь доступно.







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







Вот как выглядит схема нового дата-центра контейнерного, вот это 4 контейнера, один из них обитаемый. Это контейнер под климатическое оборудование, чиллеры, это контейнер под ИБП, это контейнер под IT-оборудование. В принципе, видно, что его можно линейно масштабировать это решение до нужных вам объемов, т.е. это не конечное решение.







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








Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/305430/

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

Закон «О персональных данных» и практика его применения в российской действительности

Пятница, 08 Апреля 2016 г. 13:01 (ссылка)





Как известно, в России несколько лет действует Федеральный Закон №152 «О персональных данных».

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



Любое юридическое лицо, организованное в российском правовом поле подпадает под данное регулирование. Наш проект RUVDS Закон затрагивает как в части обработки личных данных клиентов, так и защиты информации, с которой работают клиенты на нашем оборудовании.



Есть несколько объектов защиты.



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



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



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



Каким образом можно организовать защиту данных?



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

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



Естественно, есть разные способы и уровни защиты данных.



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



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



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



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



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

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

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



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

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



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



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

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



Зачем такие меры?



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



Так же не стоит забывать об отказоустойчивости и хранении резервных копий данных. Хотя сам факт отказа всего сервера крайне маловероятен, почти невозможен, всегда должна быть система зеркалирования данных, а для серьезных клиентов, по запросу, как правило, выделяется двойной объем дисков для постоянного бэкапирования. Это актуально как раз банкам, особенно тем, кто развернул интернет-банк на сервере, ведь они должны максимально быстро «поднять» резервную копию ресурса. Такая система это позволяет сделать и у нас она тоже есть.

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

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



Если вы используете виртуальный сервер, подобные вопросы решаются мгновенно. Вы просто дозаказываете ресурс и компания выделяет для вас нужные мощности. Происходит это обычно с течение нескольких минут. Если вы так разрослись, что для вас уже не хватает одного сервера и данные нужно перенести на новый более мощный сервер, это займет пару часов. Но в любом случае, по сравнению с покупкой и настройкой своего железа – это молниеносно. А цена будет на порядки ниже. К примеру, аренда сервера, мощностью в хороший ноутбук, стоимостью 50 000 рублей, вам обойдется в 1 500 рублей (это без учета скидок за оплату за год). Сами понимаете, какая экономия. Это не говоря о том, что на машине могут работать сразу много сотрудников, подключаясь к ним со слабого дешевого ПК или даже с планшета. Так же к этому нужно добавит экономию на покупке программного обеспечения. Вы можете арендовать практически любое ПО для деятельности вашей команды у хостинг-провайдера.



Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/281230/

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

Планирование вычислительных ресурсов и выбор серверов для RUVDS

Среда, 06 Апреля 2016 г. 17:58 (ссылка)





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

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

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



При выборе серверов для RUVDS руководствовались следующими требованиями:

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

• В каждом сервере должно быть не менее 4 процессоров и не менее 128 ГБайт оперативной памяти. Данное требование вызвано тем, что серверы используются для создания виртуальных пулов ресурсов.



Основываясь на этих требованиях, для клиентов проекта RUVDS мы выбрали блэйд-серверы с не менее чем 4 процессорами Intel Xeon последних поколений и не менее чем 384Гб оперативной памяти.



Пример планирования количества серверов

Для расчета используются значения SPECint2006 Rates. Значение SPEC взяты на сайте www.spec.org/cgi-bin/osgresults?conf=rint2006.

Далее приведены два способа расчета: способ оценочного расчета на основании расчета общих требования к параметрам SPEC и точный способ на основании преобразования значения SPEC в количество vCPU с последующим преобразованием количества vCPU в количество серверов.

Данные расчеты приведены в качестве примера, чтобы понять, как проводится расчет количества серверов.




Способ 1: расчет на основании общих требований к параметрам SPEC

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



Пример расчета приведен ниже.

Средний коэффициент загрузки ЦП для 107 серверов Dell PowerEdge 2950 (8 Гбайт памяти и два ЦП E5420 с основной частотой 2,5 ГГц и четырьмя ядрами) составляет 20%. Значение SPEC равно 118 (оно получено на сайте www.spec.org/cgi-bin/osgresults?conf=rint2006).

Требуется осуществить миграцию прикладных систем на серверы RH5885 (каждый с четырьмя восьмиядерными ЦП E7-4820 с основной частотой 2 ГГц). Значение SPEC равно 775.

Следовательно, количество серверов можно рассчитать по следующим формулам:

Потребность в вычислительной мощности =

https://habrahabr.ru/post/281086/

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

RUVDS благодарит пользователей Хабрахабр за сделанный выбор

Вторник, 05 Апреля 2016 г. 13:12 (ссылка)

По независимой оценке, Пользователя AlexeyKh сервера RUVDS признаны лучшими среди протестированных VDS/VPS серверов на Windows.

В честь этого события, специально для читателей блога habrahabr проект виртуального хостинга RUVDS предоставляет уникальную скидку на свои услуги.



Воспользуйтесь промо-кодом на баннере и получите скидку до 50% на любую конфигурацию VDS сервера.

Условия акции: базовая скидка по промо-коду 30%, скидка по промо-коду суммируется со скидкой при оплате за 3, 6 или 12 месяцев. Таким образом при оплате за 3 месяца общая скидка составит 35%, при оплате за 6 месяцев – 40%, при оплате за год – 50%.



Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/280964/

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

RUVDS запускает партнерскую программу

Пятница, 01 Апреля 2016 г. 15:32 (ссылка)

Партнерская программа — это формат рекламной активности сервиса, направленный на увеличение продаж. RUVDS предоставляет участникам партнерки ссылки для рекламы своих серверов и выплачивает процент с покупок, совершенных пришедшими по рекламе партнера клиентами.

image

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

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

Вы можете просто рекомендовать наши VPS/VDS сервера своим друзьям и клиентам и зарабатывать с продаж с того момента, когда покупатель приобретает сервер.



5 причин стать нашим партнером:



1.Мы гарантированно выплачиваем комиссионные по вашему требованию.

2.Ваш заработок составит от 15% до 25%.

3.Пригласив клиента один раз, вы зарабатываете на нем пожизненно.

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

5.Участвуя в партнёрской программе RUVDS, Вы можете значительно сократить расходы на оплату своего виртуального сервера, а также неплохо заработать!



Несколько рекомендаций по эффективному размещению свой партнерской ссылки:

социальные сети

тематические блоги

тематические форумы

оставлять комментарии к каким-то тематическим постам

электронные письма друзьям и знакомым

рассылки по подписчикам вашей группы, сайта



Подробнее об условиях и способе подключения к партнерской программе по ссылке ruvds.com/partner



Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/280696/

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

Juniper MX + IX + SynFlood

Вторник, 15 Марта 2016 г. 17:24 (ссылка)

В данной статье я бы хотел рассказать об одном достаточно простом методе защиты от Syn Flood атак на маршрутизаторах Juniepr серии MX. Данный метод может помочь при нескольких условиях, о которых рассказано ниже. Конечно, есть аппаратные и программные решения, технологии Syn Cookies, Syn Proxy и другие. Но, иногда, большую часть трафика получается заблокировать на маршрутизаторе без применения дополнительных механизмов или дорогостоящих устройств. Так как мы использовали для настройки маршрутизатора некоторые статьи наших коллег, решили поделиться и нашим опытом, он достаточно специфичны, но надеемся принесет пользу. Пример такой атаки приведен на графике ниже.





Немного теории



Syn Flood — одна из разновидностей сетевых атак типа отказ от обслуживания, которая заключается в отправке большого количества SYN-запросов в достаточно короткий срок. Сам SYN пакет имеет маленький размер (с заголовками канального уровня 54+ байт), даже с полосой 1G можно генерировать большое количество пакетов в секунду. Часть провайдеров не запрещают отправку из своей сети пакетов с подменным адресом источника, и даже один сервер с полосой 1G, размещенный у такого провайдера, может генерировать атаку, которая создаст много проблем. Большинство провайдеров интернета для конечных пользователей не выпускают из своей сети пакеты с поддельным адресом источника и, как следствие, большинство атак идет именно с клиентов ДЦ, при этом количество атакующих машин невелико.



Что можно предпринять на Маршрутизаторе?



Изначально нужно исходить из того, что у нас хорошая связанность и подключено много точек обмена трафиком. Конечно, если у Вас единственный UPLINK и, предположим, Syn Flood идет с одной машины, можно попробовать проанализировать трафик, и, если человек который организует DDOS совсем ленивый и не позаботился о разных ttl, можно заблокировать трафик по ttl + dst ip. В этом случае отрежется весь трафик с данным ttl — это, безусловно, лучше, чем если бы сервер лежал совсем, но не оптимально.



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




  • DataIX

  • Cloud-IX

  • Pirix

  • WIX

  • SpbIX

  • MskIX

  • CodIX

  • GlobalIX

  • IHome



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



Как это сделать



Изначально нужно подключать IX в отдельный virtual-switch — для возможности фильтрации по MAC адресам. То есть даже при подмене src адреса пакеты будут приходить с src MAC адресом граничного маршрутизатора. Для примера можно предположить, что мы подключили только DataIX и аномальный трафик идет через него.



Конфигурация подключения IX
interfaces {
xe-0/3/0 {
description "UPLINK_IX: DATAIX XX.XX.XX.XX 255.255.252.0 (path XXX);";
flexible-vlan-tagging;
native-vlan-id 20;
encapsulation flexible-ethernet-services;
unit 0 {
encapsulation vlan-bridge;
vlan-id 20;
}
}
irb {
unit 20 {
description "DataIX route interface";
family inet {
filter {
# стандартный набор фильтров
}
address XX.XX.XX.XX/22;
}
}
}
}

firewall {
family bridge {
filter ix_mac_filter {
# пока пустой
}
}
}

protocols {
bgp {
group dataix {
# настройка BGP
}
}
}

routing-instances {
switch_dataix {
description "DATAIX - prometey XX.XX.XX.XX 255.255.252.0";
instance-type virtual-switch;
bridge-domains {
switch_dataix_bridge {
domain-type bridge;
vlan-id 20;
interface xe-0/3/0.0;
routing-interface irb.20;
forwarding-options {
filter {
input ix_mac_filter;
}
}
}
}
}
}


Далее можно посмотреть MAC адреса, которые пришли с данного IX:

root@rt01> show bridge mac-table
MAC flags (S -static MAC, D -dynamic MAC, L -locally learned, C -Control MAC
SE -Statistics enabled, NM -Non configured MAC, R -Remote PE MAC)

Routing instance : switch_dataix
Bridging domain : switch_dataix_bridge, VLAN : 20
MAC MAC Logical NH RTR
address flags interface Index ID
00:01:e8:a3:ed:20 D,SE xe-0/3/0.0
00:03:fe:0a:ac:00 D,SE xe-0/3/0.0
00:04:80:f4:bc:00 D,SE xe-0/3/0.0
00:04:96:51:ba:84 D,SE xe-0/3/0.0
00:04:96:52:05:a4 D,SE xe-0/3/0.0
00:04:96:52:05:ea D,SE xe-0/3/0.0
00:04:96:52:06:14 D,SE xe-0/3/0.0
00:04:96:6d:13:a9 D,SE xe-0/3/0.0
00:04:96:6d:14:79 D,SE xe-0/3/0.0
00:04:96:6d:17:79 D,SE xe-0/3/0.0
00:04:96:6d:52:3e D,SE xe-0/3/0.0
00:04:96:6d:5b:26 D,SE xe-0/3/0.0
00:04:96:6d:6f:f0 D,SE xe-0/3/0.0
00:04:96:7d:bf:68 D,SE xe-0/3/0.0
00:04:96:7d:f8:99 D,SE xe-0/3/0.0
...
И на основе этих данных можно составить фильтр, который будет подсчитывать количество пакетов, пришедших с MAC адреса на атакуемый сервер:

filter ix_mac_filter {
term 00:01:e8:a3:ed:20 {
from {
source-mac-address {
00:01:e8:a3:ed:20/48;
}
ip-destination-address {
# адрес атакуемого сервера
}
}
then {
count 00:01:e8:a3:ed:20;
accept;
}
}
term 00:03:fe:0a:ac:00 {
from {
source-mac-address {
00:03:fe:0a:ac:00/48;
}
ip-destination-address {
# адрес атакуемого сервера
}
}
then {
count 00:03:fe:0a:ac:00;
accept;
}
}
term other {
then {
count other;
accept;
}
}
Судя по документации в маршрутизаторах Juniper серии MX есть ограничение в 1024 правила с действием counter, но в данный лимит мы не упирались. Сбрасываем состояние счетчиков в данном фильтре и через некоторое время (1-2 минуты) смотрим на результат:

root@rt01> clear firewall filter ix_mac_filter  
root@rt01> show firewall filter ix_mac_filter

Filter: ix_mac_filter
Counters:
Name Bytes Packets
00:01:e8:a3:ed:20 142632382856 288079929
00:02:4a:2f:a0:1a 5159885 75880
00:03:fe:0a:ac:00 14915791420 72085522
00:04:96:6d:6f:f0 2508125168 35985837
00:04:96:7d:f8:99 362692758 5352205
00:04:96:82:4d:57 216046092 2851369
...


И, если находится аномалия, смотрим какой IP адрес связан с этим MAC адресом, далее смотрим кому он принадлежит, и, если это не шлюз, устанавливаем политику reject. Тем самым минимизируя последствия атаки.



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



пс. После установки в одно шасси DPCe и MPC данная схема стала работать не совсем корректно, часть пакетов в фильтре просто не видится. Если кто подскажет почему, буду благодарен.



Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/278613/

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
Троян_95

Хостинг-провайдер нового поколения VPS.house

Суббота, 13 Февраля 2016 г. 13:29 (ссылка)


LOGO



На правах рекламы... Для всех российских пользователей отличной новостью будет узнать, кто еще не в курсе, о хостинг-провайдере нового поколения VPS.house, посредством которого можно воспользоваться услугами по аренде виртуального сервера (VPS/VDS). Виртуальные сервера на vps.house, размещаемые в сертифицированном дата-центре в Москве, поэтому и в связи со вступлением в силу федерального закона «О персональных данных», который обязывает компании хранить персональные данные граждан РФ исключительно на территории России эти сервера идеально всем подходят.



Представьте себе, на протяжении минуты виртуальный сервер будет автоматически установлен на vps.house, мало того, он тут же станет годным к работе подключения по RDP. Беспокоится пользователю не стоит даже в случае опасности, так как предусмотрена эффективная защита виртуальных серверов от всех популярных видов DDoS-атак мощностью до 1000 Гбит/с по цене 800 руб в месяц.



По описанию и наличию позитива все больше похоже на сказку, но это не она, это реальность! Мало того, на период экономического кризиса интересным будет узнать, что цена за услуги фиксирована в рублях и составляет от 550 руб. в месяц, хотя есть и еще приятнее новость: при оплате за год получите 30% скидку. Кроме прочего, в Вашем распоряжении целая неделя бесплатного тестового режима.



Обратите внимание, речь идет не о мышеловке: в спектре услуг -  бесплатно любая серверная ОС Windows (2003, 2008 или 2012), включая последние обновления, ну разве не уникальное и своевременное предложение?!



Вот такой он хостинг-провайдер нового поколения VPS.house, поспешите воспользоваться!!! Не стоит упускать шанс! Тестируйте!


Метки:   Комментарии (3)КомментироватьВ цитатник или сообщество
Портал_Солнцево

Надёжные серверы Dedicated от хостинг-провайдера №1!

Четверг, 14 Января 2016 г. 10:05 (ссылка)
domain-rf.ru/?p=547


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

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

Успешные клиенты Inoventica Services (LOM history — история в деталях)

Пятница, 27 Ноября 2015 г. 12:42 (ссылка)


Название компании: LOM

Сфера деятельности: изготовление бижутерии – копий исторических украшений

Сайт:

http://www.lom-history.ru/

Возраст компании: 5 лет

С нами: 1 год



Успешные клиенты Inoventica Services. Lom history - история в деталях



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

Читать дальше →

http://habrahabr.ru/post/271839/

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

Инфраструктура Amazon Web Services изнутри. Часть 2

Воскресенье, 18 Октября 2015 г. 18:28 (ссылка)





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



Сейчас в распоряжении Amazon Web Services — минимум 30 дата-центров, причем руководство планирует построить дополнительно 10 или 15 новых. Большинство дата-центров размещаются в северной Вирджинии, здесь за работу AWS отвечает примерно 20 дата-центров, общей мощностью примерно в 500 МВт. Но география инфраструктуры дата-центров AWS не ограничена только лишь Вирджинией. Сейчас три крупных кампуса ДЦ строится в Огайо, плюс облачные дата-центры работают еще в Ирландии, Бразилии, Китае, Японии, Австралии и Сингапуре.







Компания также управляет беспроводной сетью для подержки CloudFront CDN.



Что касается США, здесь дата-центры компании объединены в две группы — одна на Западном и одна на Восточном побережье. Это позволяет обеспечить равномерную передачу данных по континенту, с минимальными задержками. Плюс ко всему, хабы дата-центров США обеспечивают и поддержку клиентов в других регионах. Например, хаб на Восточном побережье обслуживает Европу, на Западном — Азию. Такая конфигурация сети также позволяет дублировать временно простаивающие ДЦ (например, из-за катастрофы) без проблем для работы AWS.



Аналогичный принцип работы используют Google и Facebook, у которых есть собственные серверные фермы в Орегоне и Северной Каролине. Для Amazon изначальным ядром всей инфраструктуры является Северная Вирджиния.



Северная Вирджиния



Поскольку сейчас сетевая инфраструктура компании распространяется по всему миру, ДЦ компании есть во многих региона. Но основа — это 23 дата-центра в округах Loudoun и Prince William. Почему здесь так много дата-центров компании? Дело в том, что здесь соединяются практически все важные сети, включая хаб Equinix.



Девять ДЦ компании располагаются в Стерлинге, пять — в Осборне, 6 — в Манассас и два — в Чантилли. Такое расположение дата-центров обеспечивает передачу данных с очень малыми задержками между Availability Zones, клиенты компании могут использовать истансы в различных регионах, для обеспечения беспрерывности работы на случай непредвиденных ситуаций (например, природные катастрофы).



Как результат — Восточное побережье США имеет наибольшее количество дата-центров Amazon Web Services, причем компания продолжает расширять инфраструктуру, добавляя дата-центры в систему. Здесь общая мощность ДЦ достигает около 500 МВт.







Орегон и Калифорния



С 2009 года Amazon строит свои дата-центры и на севере Калифорнии. Правда, электричество здесь довольно дорогое, поэтому компания больше ориентируется на Орегон, отстраивая свои дата-центры в небольших городках вдоль реки Коламбия.



В Орегоне строится не только Amazon, но и многие другие компании. Здесь сразу несколько причин:




  • Прохладный климат, который позволяет использовать наружный воздух для охлаждения своих систем;

  • Выгодная для бизнеса система налогообложения;

  • Энергия от гидроэлектростанций, расположенных на реке.



Последний фактор дает Amazon еще одно преимущество — повышение своего рейтинга в списке «зеленых» компаний. Да, ГЭС наносят урон окружающей среде, но не такой значительный, как те же тепловые электростанции.



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



Компания уже заявила что надеется построить в Орегоне еще 15 дата-центров.



Огайо



Рукводство компании заявило о намерении инвестировать около $1,1 млрд в создание кампуса дата-центров сразу в трех локациях: Дублине, Хиллиарде и Нью Олбани. В каждом кампусе будет до 5 дата-центров с 18 резервными генераторами мощностью в 2,5 МВт каждый.



Эта информация позволяет судить о совокупной мощности каждого кампуса — около 32 МВт.



У AWS, как и говорилось выше, для обеспечения работы сети CloudFront в управлении находится около 40 edge-нод по всему миру.



Original source: habrahabr.ru (comments, light).

http://habrahabr.ru/post/269025/

Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

Ботнет из Linux-устройств организует DDoS-атаки с потоком трафика 150 Гбит/с и выше

Четверг, 01 Октября 2015 г. 14:49 (ссылка)

image



Ботнет из Linux-устройств разросся настолько, что может генерировать атаки с потоком более 150 Гбит/с, что многократно превышает запас прочности инфраструктуры среднестатистической компании. О начале подобных DDoS-атак сообщили исследователи из Akamai Technologies.



Сетевой червь, более известный как XOR DDoS, при помощи которого и был собран ботнет, выявили еще в сентябре 2014 года. В январе этого года пользователь Хабра Patr1ot07 опубликовал статью, в которой рассказал о том, как работает зловред.



Инфицирование начинается с попытки брут-форса SSH, используя логин root. В случае успеха злоумышленники получают доступ к скомпрометированной машине, а затем устанавливают троян, как правило, с помощью шелл-скрипта. Скрипт содержит такие процедуры, как main, check, compiler, uncompress, setup, generate, upload, checkbuild и т.д. и переменные __host_32__, __host_64__, __kernel__, __remote__,, и т.д. Процедура main расшифровывает и выбирает C&C сервер, основываясь на архитектуре системы.




Исследователи из Akamai Technologies утверждают, что последние DDoS-атаки ботнета имели «мощность» от нескольких, до 150 Гбит/с, а нападению подвергаются до двадцати целей в сутки. Пока основной удар принимает на себя азиатский регион — более 90% целей ботнета XOR DDoS находится именно там. Атакуют, в основном, компании работающие в сфере онлайн-игр, а также образовательные учреждения.



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



На форумах в сети пишут, что малварь проживает в /lib/libgcc4.so, а в /etc/crontab прописано ее перманентное сохранение с трехминутным таймингом на проверку ( */3 * * * * root /etc/cron.hourly/udev.sh ). Даже если crontab будет вычищен, но XOR DDoS продолжит работать, запись о нем будет восстановлена в полночь пятницы. Полностью с постом об этом можно ознакомиться тут.



«Десять лет назад Linux позиционировался как безопасная альтернатива Windows, которая в то время серьезно страдала от атак, львиная доля которых приходилась именно на это семейство ОС. Из-за этого Linux все чаще и чаще применялся и применяется для повышения уровня информационной безопасности, но поскольку сфера применения этой системы расширилась, расширились и возможности киберпреступников. Сейчас злоумышленники активно развивают тактику и инструментарий для атак на Linux-системы, поэтому системные администраторы и специалисты по безопасности должны ужесточать свою политику на местах», — прокомментировали в Akamai Technologies.



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



Original source: habrahabr.ru (comments, light).

http://habrahabr.ru/post/268007/

Комментарии (0)КомментироватьВ цитатник или сообщество

Следующие 30  »

<хостинг-провайдер - Самое интересное в блогах

Страницы: [1] 2 3 ..
.. 10

LiveInternet.Ru Ссылки: на главную|почта|знакомства|одноклассники|фото|открытки|тесты|чат
О проекте: помощь|контакты|разместить рекламу|версия для pda