Software Defined XXX

В последнее время стала наблюдаться путаница в терминологии, в особенности подогреваемая различными маркетинговыми публикациями. Software Defined XXX, XaaS, Internet of things и так далее. Попробуем с этим разобраться.

XaaS - X-as-a-Service, что-то как услуга. Стандартный термин для облачных услуг (соответствующих определению NIST). X - конкретная услуга или класс услуг.
Software Defined XXX - программно определяемое XXX. Смысл термина - подчеркнуть отказ от специализированного оборудования в пользу стандартных серверов. Весь функционал продукта определяется не аппаратной начинкой и специальными процессорами, а исключительно залитым софтом.

В частности, есть понятие Software Defined Storage (SDS). Т.е. система хранения данных, построенная на стандартных компонентах, которые можно купить условно в любом магазине.

С другой стороны интеграция различных компонентов позволила появиться конвергентным решениям. Например, объединение трафика Fiber Channel и Ethernet в Cisco UCS и передача его по одному совмещенному каналу. При дальнейшей интеграции появились конвергентные решения - все-в-1, объединяющие в себе ресурсы хранения, сети передачи данных и вычислительные мощности. Пример - VCE Vblock, FlexPod и другие.
На границе Software Defined и конвергентных решений появился новый класс - гиперконвергентные решения, внутри которых используется только стандартное commodity оборудование, и все определяется системным ПО. Примеры - Nutanix, Simplivity, VMware EVO:RAIL.

И здесь есть определенный тонкий момент - внутри этих систем применяется Software Defined Storage для агрегации сырых ресурсов с физических дисков в логические пулы, но сама гиперконвергентная система не является SDS. Отличительная особенность - SDS построена для того, чтобы экспортировать ресурсы хранения до клиента. Гиперконвергентная система наоборот, потребляет эти ресурсы, предоставляя клиенту возможность обработки информации.

Иными словами, Nutanix не является Software Defined Storage.

EMC RecoverPoint для виртуальных машин

EMC представила RecoverPoint for VMs специально для приложений, работающих в облаках на базе vSphere. RPVM управляется при помощи vCenter plug-in, разворачивается как виртуальный модуль (virtual appliance). Так же, как и старший брат, использует сплиттеры, но в этом случае не на уровне СХД или коммутации, а прямо в ядре ESXi. В силу чего работает с вообще любой СХД, вне зависимости от того SAN, NAS это или DAS. В том числе поддерживается и VMware VSAN.

 

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

RecoverPoint for VMs рассчитан на инсталляцию инженерами заказчика через простой и понятный мастер. Сплиттер содержится в маленьком VIB файле и поддерживает vSpeher 5.1u1 и 5.5. Разумеется, VIB должен быть установлен на всех хостах, где может обитать защищаемая ВМ. 

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

Оригинал: Nick Fritsch

VMworld 2014. День 1.

Итоги и анонсы первого дня VMworld.

EVO: RAIL

Долгожданный и обросший слухами VMware Marvin - гиперконвергентный appliance (пока не могу найти адекватного перевода), построенный партнерами и использующий пакет ПО EVO:RAIL. Объявленные партнеры: Dell, EMC, Fujitsu, HP, inspur, net one, Super  Micro. 

Подробности о том, что внутри.

VMware vRealize

vRealize - новая платформа управления облаком, расширяющая возможности мониторинга и управлеия за пределы датацентра. Не только публичные облака, но также и не VMware инфраструктуры будут поддерживаться. VMware vCloud Suite предоставит инфраструктуру для частного облака, vCloud Air (ex-vCloud Hybrid Service) для публичного, а vRealize накроет общим зонтиком.

 

vCloud Suite 5.8

До 6ки не дотянули, она будет вместе с vSphere 6, которая сейчас только в бете. Но в 5.8 интересное добавление - усиление функционала по непрерывности бизнеса и восстановлению после катастроф путем планирования и самообслуживания.

Hadoop

Добавлены 2 расширения класса Big Data для создания приложений нового поколения.

NSX

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

 

OpenStack

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

 

VMware Integrated OpenStack (VIO) - это готовый .OVA шаблон со всем, что нужно для развертывания и управления облаком OpenStack.

Общий итог

Отличная подборка материалов от парней из UP2V для тех, что владеет английским.

http://up2v.nl/2014/08/25/a-summary-of-vmworld-2014-annoucements/

1. Announcement of EVO:RAIL. An appliance installed with software based on vSphere, VSAN with a nice HTML5 interface. Initially 6 serverhardware vendors will sell and support.
2. vSphere 6.0 Beta
3. Virtual Volumes and VSAN 2.0 Beta
4. Introduction of vRealize Suite, a cloud management platform
5. Announcement of Site Recovery Manager 5.8 and vSphere Data Protection 5.8
6. vCloud Suite 5.8
7. vRealize Cloud Management Platform
8. vCloud Air OnDemand GA 2015. Beta program starts August 25 ! Join the beta here
9. vCloud Air for Government  Services (FEDRAMP certified) will roll out in US in September
10. Tech Preview: vCloud Air Object Storage based on EMC Viper technology.
11. vCloud Air Database as a Service
12. AirWatch available on vCloud Air
13. introduction of vRealize Operations Insight (“vROI”)
14. VMware NSX for vSphere 6.1 . Info here as well
15. VMware is  Now an Open Compute Project Gold Level Member
16. VMware Partners With Docker, Pivotal And Google To Bring Container Support To Its Platform . See also this Docker blog.
17. Project Fargo, for faster, more compliant, lighter-weight containers on VMware’s SDDC platform
18. Announcement of a technical preview of EVO:RACK. The big brother of EVO:RAIL.
19. Announcement of private beta of VMware integrated OpenStack (VIO)

A few days before VMworld started the following listed below was announced.

1. The rebranding of vCloud Hybrid Services to vCloud Air
2. The acquisition of CloudVolumes by VMware
3. Ubuntu available on vCloud Air

Оригинал: Julian Wood

Insider threat for Cloud. Some thoughts.

As we move towards 100% virtualization the role of vAdministrator appears more and more important. vAdmin can rule all the infrastructure from one single console, unlike years before. One of Top3 US banks can be brought down completely by a single script, imagine that!
We start to see more and more cases when fired admin log in to ex-employers infrastructure via McDonalds WiFi and delete some critical data.
Let’s take CodeSpaces example - hackers wanted a lot of money, but didn’t get it. So they just deleted everything, including backups. 

The only thing growing faster than IT security spending is the cost of security beaches. That’s the reality we see today.

Without any questions level of control will be increasing as well as pressing on privileged users and admins. But what really surprised me - 4 security pros on the stage have said nothing about organizational problems in this security nightmare with insiders.

Let’s think about it a little. Insider is the person inside the company - employee most of time. And we can divide them into 3 basic categories:
1) These people will do something bad and sell company’s secrets no matter what.
2) People who can do something bad or do nothing.
3) Angels. They will do nothing bad even if management will do something bad to them. 

Type 1 insiders should be discovered ASAP, ideally even on interview - that’s why there are HR professionals involved and background checks performed. 
Type 3 insiders are not a threat. 

There are still type 2 people left, and that’s the type we ignore. Majority of any employees in any company. These people will do something bad as retaliation, they will not strike first. And guess what we’re doing to them?
- put under suspicion and constant control
- treat all their activity as they’re type 1 people
- completely ignore their personality, treating like replaceable and expendable working unit.

I can assure you - nothing is more stimulating like this kind of treatment for employer when you have an access to most critical services.

There is NO statistics on percentage of incidents caused by bad management treating employees like a trash. And we try to solve organizational problem technically, without any human interaction. Is this because we’re techno geeks lacking social skills or just because it’s more difficult and complex than to put web cams everywhere including restrooms?
At some point there can be ONLY trust. Imagine you’re on the operating table - how can you enforce security and be sure surgeon will do only permitted actions? There is no way, period. We’re giving very high rights to the surgeon, and we’re (society) also give very high responsibility.
Virtualization administrator with highest access is the very same surgeon operating on organization’s IT heart, sometimes while the heart still beats. So why we take a look on what admin is doing and not on how manager treats him / her?

So, after years of experience and thoughts I see 2 basic rules of information security when we talk about these type 2 guys and gals with full access. 

1) Insider threat becomes VERY real when you treat your employees and colleagues as insiders and threat instead of people who help. When you see them as easily replaceable and expendable working units.
2) Employee’s loyalty to company starts with company’s loyalty to employee.

We should solve organizational and administrative problems first, otherwise technical solutions will be useless. Or even they will even lower overall security.
 

Inspired by SEC2296.

Угроза от инсайдера в облачной инфраструктуре

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

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

В итоге безусловно будет усиливаться контроль и прессинг в сторону привилегированных пользователей и администраторов. Но что меня удивило - даже от самых профи, сидевших на сцене, я не слышал одного. Я не слышал даже подтверждения наличия чисто административной проблемы с инсайдерами.
Инсайдеров можно разделить на несколько типов:
1) Сделают гадость и продадут данные вне зависимости ни от чего
2) Могут сделать, а могут и не делать
3) Не будут делать гадость, даже если с ними обойдутся очень нехорошо.

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

В конечном итоге у меня сформулировалась пара тезисов по облачной безопасности:
1) Угроза от инсайдера всерьез начинается, когда сотрудников рассматривают как инсайдеров и угрозу, а не помощников. Когда их рассматривают в качестве легко заменяемых ресурсов, а не людей. 
2) Лояльность сотрудника к компании начинается с лояльности компании к сотруднику.

Выступающие не смогли ответить на вопрос: какой процент инцидентов с инсайдерами был вызван плохим отношением менеджмента к “инсайдерам”? Подразделения по ИБ НЕ занимаются этим вопросом.

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

По мотивам сессии SEC2296.

VMworld 2014. EVO:RAIL

VMworld еще толком не начался, а новости уже огого! Анонсирована EVO:Rail - гиперконвергентная инфраструктура от VMware, состоящая из пакета ПО EVO:RAIL и 2U железки из 4х узлов. VMware не будет поставлять аппаратную часть, что дает четкий ответ НЕТ на ранее звучавший вопрос: VMware пойдет в железный бизнес? Аппаратную часть будут поставлять партнеры, и можно ожидать первые EVO:RAIL совместимые предложения уже на этой неделе.
В качестве основной СХД будет использоваться vSAN, а софт EVO:RAIL - это простая инсталляция (15 минут) всего (ESXi и vCenter) и простое администрирование.

 

Аппаратная часть состоит из 4 независимых узлов (серверов) в едином шасси, в каждом из которых по 2 процессора и 192ГБ память. Подсистема хранения гибридная (Flash и HDD) с окончательной емкостью 16ТБ. Софт включает в себя vSphere Enterprise Plus, а также vCenter Log Insight. Расширяется до 4 шасси в версии 1.0.

 

 

Вычислительный блок

• Dual socket – Intel Xeon E5 2620v2 CPUs, 6-core
• Memory – up to192 GB
• 1 x Expansion Slots PCI-E
• Disk controller with pass through capabilities (Virtual SAN requirement)

Ресурсы хранения

• 1 x 146 GB SAS 10K-RPM HDD or 32 GB SATADOM (ESXi boot)
• 1 x SSD up to 400 GB (Virtual SAN requirement for read/write cache)
• 3 x 1.2 TB SAS 10K-RPM HDD (Virtual SAN data store)

Внешние интерфейсы

• 2 x Network – 10 GbE RJ45 or SFP+
• 1 x Management RJ45 – 100/1000 NIC

Вероятно выглядеть будет как-то так…

Необходимо заметить, что коммутатор top-of-the-rack дожен быть 10Гбит с поддержкой VLAN.

Софт

EVO: RAIL - первая гиперконвергентная инфраструктура, полностью от VMware и включает в себя:

• EVO: RAIL Deployment, Configuration, and Management
• VMware vSphere® Enterprise Plus, including ESXi for compute
• Virtual SAN for storage
• vCenter Server™
• vCenter Log Insight™

Простое конфигурирование – EVO: RAIL поддерживает 3 конфигурации.

Попрощайтесь с Flash, его больше нет - теперь только HTML 5. 

3 варианта конфигурации:

• Just Go – все автоматически, включая IP адреса и имена хостов. Прекрасный вариант для “green field” инсталляций без участия пользователя. Тем не менее, будет необходимо сконфигурировать top-of-the-rack коммутатор и воткнуть кабели.
• Customize Me – в этом вариант от пользователя требуется ввод имен хостов (vCenter and ESXi), сетевой информации (IP ranges, VLAN IDs, VSAN, vMotion, vCenter server, VM networks),  паролей (vCenter and ESXi), глобальной инфраструктуры (time zone, NTP server, DNS, AD, proxy, syslog logging or vCenter Log Insight)
• Upload Configuration – в этом варианте вся конфигурация загружается, например, с USB флэшки. Файл конфигурации - просто JSON на основе XML.

EVO: RAIL софт затем инсталлирует гипервизоры и vCenter Server, конфигурирует кластер и активирует различные сервисы (VSAN, HA, vMotion…). 

Manual configuration – вводим префикс имен хостов, информацию о vCenter и домене:

Конфигурация VM Networking

Управление EVO: RAIL

Пакет EVO: RAIL позволяет не только установить и сконфигурировать инфраструктуру (ESXi and vSphere), но так же позовляет и управлять виртуальными машинами. Правда возможности эти довольно таки ограничены.

Вот пример создания ВМ - через мастер.

После создания можно управлять виртуальной машиной через тот же интерфейс.

Страница управления лицензиями и языком интерфейса. Нужен всего один серийный номер на всю инфраструктуру! Отсюда же можно выгрузить логи.

В версии 1.0 возможно расширение до 4х узлов (16 хостов ESXi), но данное ограничение в будущем будет снято.

Отказоустойчивость!

Распределенный “RAID” EVO:RAIL на основе VSAN выдерживает отказ оборудования без потери данных или простоя. Любой узел уходи в даун - VSAN немедленно начинает ребилд ВМ, работавших на отказавшем узле.

Сетевые требования

Уже было упомнято, что top-of-the-rack коммутатор должен быть 10Гбит.

VMware рекомедует изоляцию всех видов трафика через использование VLAN. VSAN требует L2 multicast (IGMP Snooping + IGMP Querier). Так же необходимо включение IPV6.

Новые узлы обнаруживаются автоматически

Пример обнаружения ошибки в конфигурации:

Интеграция с Log Insight:

Конфигурация 4х узлов и инсталляция vCenter занимают примерно 15 минут.

И наконец!

Добавление новых узлов EVO:RAIL очень простое, система автоматически обнаруживает включенные узлы - и нужно только нажать на зеленую кнопку.

Добавить всего два пароля:

• ESXi password
• vCenter password

Вся сетевая информация берется из пула IP, созданного при конфигурировании первого узла.

 

Проект MARVIN, ранее упоминавшийся на просторах интернет, теперь называется EVO:RAIL. Все начиналось в январе 2013, а уже в 4м квартале 2014 можно будет приобрести.

Оригинал: Vladan Seget

SLA? Это ли нужно для частных облаков?

Часто слышу аббревиатуру SLA. Причем в контексте "у нас есть SLA, а значит есть облако".

Нет, мои дорогие. В большинстве случаев (90%+) то, что у вас есть - это даже не SLA.
Давайте разберемся с терминологией:
SLO (Service Level Objective) - заданный уровень качества сервиса. Зачастую выражается в девятках, иногда в простоях в год (равнозначно). Что же такое девятки и их количество? Пять девяток, известные как "офигеть как круто", означают, что сервис доступен 99,999% времени (допускается простой пять с половиной минут в год).
Но в большинстве случаев путают SLA и SLO. В чем же принципиальная разница между ними?
SLA (Service Level Agreement) = SLO + штрафные санкции. В случае отсутствия четко прописанных штрафных санкций не может идти речи ни о как каком SLA. Это не более, чем SLO с обещанием "честное слово, постараемся".

С другой стороны наблюдается проблема неспособности бизнес-подразделений сформулировать хоть сколько-нибудь внятные цифры SLO. Архитектор приходит к бизнесу и спрашивает - а сколько для компании будет стоить потеря данных за последний час, и сколько будет стоить один час простоя сервиса? И бизнес потерялся. Их никогда не спрашивали об этом, никто никогда даже не задумывался.
Зачем это спрашивает архитектор? Затем, что при вопросе какие вы хотите увидеть в SLO показатели RPO (Recovery Point Objective) и RTO (Recovery Time Objective), следует ответ - конечно же ноль. Архитектор проектирует систему с простоем, стремящимся к нулю, и нулевой потерей данных. У бизнес-подразделения глаза лезут на лоб от стоимости.

Мало назначить RPO(RTO), надо обосновать почему именно такая цифра должна стоять. Исполнение заданных в SLO цифр несет определенные расходы на внедрение и поддержку, и это тоже нужно учитывать. Лишь после можно говорить что-то о штрафных санкциях и SLA.
В большинстве случаев же штрафные санкции за неисполнение будут заключаться в "генеральный намылил часть тела CIO прямо на собрании директоров". За что ему намылили? За то, что "система из говна и палок не шмагла..."

Нет, ну серьезно, какие тут SLA и облака, если из говна и палок?

Что такое частное облако?

Только очень ленивый не писал и рассказывал за последние 5 лет про облака. И если насчет публичных облаков мы худо-бедно сходимся в понятиях, спасибо NIST, то насчет частных до сих пор никак не договоримся.
Что же такое частные облака и чем они отличаются от простой виртуальной фермы? Впрочем, а кто сказал, что они отличаются?
Давайте посмотрим, как же ложится НИСТовское определение облачных услуг с их 5ю непременными атрибутами на частные инфраструктуры.

• On-demand self-service, оно же самообслуживание по требованию. Пользователем частного облака с позиции IaaS является ИТ-администратор подразделения, запрашивающего ресурсы. Если речь идет не о крупном холдинге с выделенным сервисно-провайдерским подразделением, то пользователь IaaS является одновременно и поставщиком IaaS. Если читать определение подробно, то самообслуживание по требованию – это возможность самостоятельно заказывать ресурсы, без необходимости взаимодействия с сотрудниками поставщика. Т.е. при строгом следовании определению ИТ-администратор не обязан взаимодействовать сам с собой. Что разумеется теряет смысл как вырожденный случай. Иными словами, атрибут номер 1, «самообслуживание» для большинства частных облаком является опциональным, и применимым значительно больше в аспекте SaaS к конечным пользователям.
• Broad network access, широкий (универсальный) сетевой доступ. В отличие от публичных облаков требования к частным оказываются куда более мягкими, поскольку есть всего один потребитель услуг, о котором известно все. Можно считать этот атрибут выполняемым по умолчанию.
• Resource pooling, объединение ресурсов в общие пулы. Нет вопросов, виртуализация на всех уровнях и пулы должны быть.
• Rapid elasticity, мгновенная эластичность. Эластичность частных облаков ограничена сверху имеющимся набором оборудования и физической невозможностью установки дополнительных ресурсов «вот прям щас». Т.е. частное облако имеет эластичность в пределах своих размеров с определенной гранулярностью (максимальный размер одного экземпляра ВМ, ограниченный конфигурацией физ. серверов). Либо частное облако превращается в гибридное, закупая по требованию ресурсы у облачного провайдера. Эластичность в пределах частной инфраструктуры обеспечивается платформой виртуализации, обеспечивающей так же и объединение в пулы.
• Measured service, измеряемая услуга. Пожалуй, является ключевым атрибутом облаков вообще. В случае с частными облаками модель pay-as-you-go теряет смысл, а биллинг работает в режиме перевода бюджета из одного кармана в другой. Такая модель называется chargeback, если стоимость ИТ-услуг вешается в бюджет линий бизнеса и защищается соответствующими директорами. Либо showback, если департамент ИТ просто предоставляет отчет о потребленных ресурсах различными линиями бизнеса. Причем ключевым моментом является приведение мегабитов к рублям.

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

VMUG 2014 - Проблемы с дисками?

Моя презентация на VMUG Россия 26 июня 2014. Краткий обзор VMware Pluggable Storage Architecture и гайд по траблшутингу подсистемы хранения.

VMUG Moscow 2014 Проблемы с дисками? from Anton Zhbankov

Adaptive Queueing против Storage I/O Control

В данном посте мы рассмотрим две разные технологии vSphere по управлению глубиной очереди на ESXi хостах. Очередь определяет количество запланированных операций ввода-вывода, которые могут быть отправлены к СХД. В случае с vSphere, где обычно к одному общему дисковому устройству обращается несколько хостов, может быть полезно управлять глубиной очереди в моменты нехватки ресурсов. В данной статье мы сравним Adaptive Queues и Storage I/O Control (SIOC).

Чем эти технологии отличаются?
SIOC использует концепцию уровня перегруженности основанном на задержках доступа. По сути, если задержки на определённом datastore превысят определённый порог - включится SIOC. Этот порог может быть выставлен вручную (стандартное значение 30мс) или автоматически с помощью инжектора запросов (представлен в 5.1). В случае с адаптивным управлением очередью vSphere ждёт фактического наступления нехватки ресурсов, то есть получения от СХД в ответ на запрос команды ввода-вывода SCSI команды USY или QUEUE FULL.

Какой механизм когда работает?
Обе технологии урезают глубину очереди. В случае с SIOC каждая ВМ на datastore имеет своё значение долей (shares), при этом сами ВМ могут быть на разных хостах. Когда порог превышен доступ к LUN начинает контролироваться путём управления глубиной очереди для каждого отдельного хоста, но при этом учитываются доли каждой отдельной ВМ. Возьмём, к примеру, два хоста с двумя ВМ на каждом. Если доли ВМ на первом хосте будут по 1000, а на втором по 2000, то второй хост сможет отправить в два раза больше команд в момент нехватки ресурсов. Как только ситуация нормализуется - все хосты и ВМ смогут отправлять данные без ограничений глубины очереди, и SIOC перестанет ограничивать ресурсы.

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

Когда какая технология была представлена?
SIOC впервые был представлен в vSphere 4.1 для блочных устройств и в vSphere 5.0 для NAS. Адаптивное управление очередью - в ESX 3.5U4.

Как включить данные технологии?
SIOC включается в свойствах каждого отдельного хранилища. По умолчанию данная функция выключена. Данная функция доступна только в редакции Enterprise+.

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

Итоги
Каждая функция может принести свою пользу в вашей инфраструктуре. SIOC, по сравнению с адаптивной глубиной очереди, более гибкая технология, но и доступна она только в Enterprise+. Но, в свою очередь, адаптивная очередь требует настройки на каждом отдельном хосте. Также если порты СХД используются для работы с другими ОС, не только vSphere, я рекомендую прочитать следующую статью базы данных: 1008113.

Типы архитектур систем хранения данных

Это не новая тема, я её уже освещал на VMworld 2013 на сессии STO5420. Хранилища (такие штуки которые хранят информацию, и делают разные вещи с информацией) можно разделить на 4 группы. Главное здесь не зациклиться на не основных вещах.

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

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

Поймите меня правильно - они важны, но не фундаментальны.

Тип 1. Кластеризованная архитектура (вертикально масштабируемые решения)

Такие решения характеризуются тем, что в них не используется общая память между контроллерами, и, по сути, данные находятся в кэше одного контроллера. СХД может быть A/A (оба контроллера активны), A/P (один контроллер пассивен), A/S (каждый контроллер обрабатывает свой объём данных, то есть у контроллеров ассиметричный доступ к данным).

Обработка данных такими СХД выглядит так:

Плюсы:

• Задержка между контроллерами минимальна. Практически нулевая.
• Скорость работы массива зависит от дисков.
•  Так как задержки в таких решениях минимальны, то СХД идеальны для транзакционной модели доступа к данным.
• Простая архитектура и минимальные коммуникации между контроллерами делают архитектуру очень легко расширяемой функционально (компрессия, дедупликация, тиринг).
• Легко поддерживать, управлять, настраивать.

Минусы:

•  Масштабируемость ограничена мощностью контроллера или парой. Обычно до 1000 дисков.
• Доступность данных гарантируется переключением между контроллерами. Что может привести к понижению производительности при выходе одного из строя.

Точки отказа:

•  Сам контроллер и его компоненты - железо и ПО.
• Диски, порты в фабрике и т.д.

Примеры:

• Active/Standby- Nimble, Pure Storage, Tintri, UCS Whiptail
• Active/Passive- NetApp, EMC VNX*
• Active/Active- HDS HUS, Dell Compellent, EMC VNX*, IBM V7000

 Сюда же попадает все PCIe решения типа Fusion-IO или EMC XtremCache только без отказоустойчивости. Если это решение использует специализированное ПО для обеспечения отказоустойчивости, распределённого хранилища данных, целостности данных - смотрите на ПО, оно попадает под одну из четырёх архитектур.

Поверх такого можно поставить федеративное решение, чтобы сделать их более горизонтально масштабируемыми с точки зрения управления. Однако IO будет балансироваться ровно до попадания данных на контроллер. Такие решения также могут использоваться для балансировки между контроллерами и пулами (VDM Mobility у VNX и Clustered ONTAP у NetApp). Как по мне, такое решение можно с натяжкой назвать горизонтально масштабируемым. Так как данные, так или иначе, находятся за одним или другим контроллером. Балансировка и тюнинг важны, в отличие от архитектур 2 и 3, где она просто есть.

Тип 2. Слабо связанные (горизонтально масштабируемые решения)

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

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

Обычно задержки в таких массивах прячут за хранилищем с низкой латентностью (NVRAM, SSD и т.д.), но в любом случае всегда больше задач по балансировке и копирования данных чем в обычном кластере типа 1 так как операции записи распределённые.

Иногда выделяется группа нод, хранящая только метаданные об остальных нодах. Логика сходна с федерацией в предыдущей архитектуре.

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

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

Обработка запроса на запись выглядит следующим образом:

 И, соответственно, на чтение:

Плюсы:

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

Минусы:

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

Точки отказа:

• Все отказы на ноде приводят к полному её отказу.
• Некоторые решения используют локальные RAID массивы, что приводит к тому что выход локального диска не приведёт к вывод из строя всей ноды.

Примеры:

• Аппартные решения: EMC Isilon, Dell Equallogic, HP StoreVirtual 4000
• Программные решения: VMware VSAN, IBM SONAS,  HP StoreVirtual VSA, EMC ScaleIO, VMware Virsto
• Конвергентные решения: SimpliVity, Nutanix.

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

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

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

Возьмём к примеру два решения от EMC - Isilon и XtremeIO. Не смотря на то что они оба очень похожи - оба решения горизонтально масштабируемы и оба используют Infiniband для интерконнекта разница в том, что Isilon использует Infiniband для минимизации задержек между нодами, и не использует общей памяти между нодами. Фактически, Isilon может использовать Ethernet (так и есть в VA версии), а XtremeIO зависим от RDMA.

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

Операции ввода-вывода выглядят так:

Плюсы:

• Задержки между контроллерами практически нулевые
• Задержки записи данных зависят в основном от физических дисков
• Идеально подходят для высоконагруженных систем
• Ограничением масштабируемость гарантируется производительность

Минусы:

•  Масштабируемость ограничена максимальным количеством контроллеров
• Хотя некоторые системы и используют x86 архитектуру, для них используется собственное аппаратное обеспечение. В остальных случаях используются ASIC. Оба этих фактора приводят к более долгому переходу на новые технологии.

Точки отказа:

• Архитектура разработана с учётом отсутствия или отказоустойчивости любого элемента.

Примеры:

• EMC Symmetrix VMAX
• HDS VSP
• HP 3Par

Тип 4. Распределённая архитектура без общих элементов (shared nothing)

В распределённых системах не используется общая память, данные разнесены по разным нодам, но не транзакционно, а "лениво". То есть данные записываются на одну ноду, и с определённой периодичностью (иногда) копируются на другие ноды для обеспечения защищённости. Системы данного типа не транзакционны.

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

Эта простота делает данную архитектуру самой масштабируемой из всех. У неё абсолютно никакой зависимости от аппаратного обеспечения, и практически всегда выполнена в программном виде. Масштабируется до петабайт с такой же лёгкостью как другие СХД до терабайт.  Обычно используется объектные и non-POSIX файловые системы часто даже лежащие поверх локальных ФС, используемых для базовых задач.

Примеры:

• HDFS
• EMC Atmos
• Блочный доступ в EMC ViPR
• Amazon AWS S3 (хотя никто за пределами Amazon не знает как на самом деле обстоит дело, я склоняюсь к типу 3)
• Ceph
• Openstack Swift

Оригинал: virtualgeek.typepad.com
Оригинал:  vmtyler.com