вторник, 21 июня 2016 г.

Cloud Trust.

When we talk of information security, including cloud security, most of the talk is about confidentiality. Well, as from my experience almost no one talks about 2 other parts of the triad – integrity and availability. But these attributes become crucial in cloud.

Why are we doing cloud in the first place? To cut expenses, both capital and operational – dollar saved is dollar earned. Guess what cloud provider does? The very same thing, cutting expenses as much as they could. And there is no easy answer to the question: make cloud more secure or save some money.

Let’s take an easy example, how can cloud provider protect your data confidentiality? For data at rest it’s pretty obvious answer – encryption. For data-in-flight there is no answer at all, encryption cannot protect from privileged insider – all the keys and hashes can be sniffed during live migration or through snapshotting. There are no measures to protect your data with 100% assurance, but all have costs. With the BIG providers you can be sure there are some internal security policies to prevent insider access and those who have access are not random people from the street. As cloud computing market grows we see a lot of smaller providers with nice prices for the service, but… So there are some basic questions for you provider you would really like to have an answer before moving your data:
1) Who has an access to hardware?
2) How much access do admins have?
3) Who is watching them?
4) Is there internal backup?
5) Who has an access to backups?
6) What really happens with our data when we close account?

I personally know a small company providing a very good service for accounting and supply management from the cloud. But they haven’t deleted any data in their entire history – everything is still in their databases. You closed your account 2 years ago – doesn’t matter. Data is still here.

Important part of the cloud is multitenancy – all the tenants use the very same shared hardware infrastructure, it saves money. But also it imposes new risks we never saw before cloud. Questions for provider:
1) How tenants are isolated?
2) Who grants tenant admin rights?
3) Who is watching them (both admins and tenant admins)?
4) How tenant admin is authenticated?
5) What really happens with our data when we close account?

The last question is exactly the same, but with different aspect – who ensures our data is not accessible one way or another by other tenant taking over hardware resources we used to have?
And this is an easy part, because we’re moving to integrity and availability which are most of the time considered as operations team responsibility with almost no attention from security team.

You’ve rented some VMs from the provider. How do you know where exactly data is stored and how reliable storage system is? Is it high end EMC Symmetrix system or DIY in garage 90TB storage like this one?



Most providers do not use classic corporate storage systems with known performance and proven reliability. DIY storage is way to cut really big piece of investment, but… here are 2 examples from Russian provider space:
1) “Selectel” have lost customers data several times due to problems with linux mdraid service.
2) “Cloudmouse” irreversibly lost 22 000 VMs due to problems with ceph service.

And personally I wonder – have these guys ever heard of backup? BTW have your provider heard?
Okay, I’ve scared you a little of cloud, so now let’s compare it to good old home-made IT. We’re building it for years and we know everything and control everything. Right?
98% of ITs I’ve seen – wrong. There are a lot of reasons for that, like:
1) There is just not enough qualified personnel
2) IT manager and whole IT department trying to maintain their personal importance instead of pursuing company needs
3) There were mistakes made before and company still paying for that
4) Some decisions were purely political instead of technical
5) … and this list can be 100 pages long.

So what should we do about it and what’s the magic word?

It is Trust. And particularly Cloud Trust. I’ve tried to extract the meaning of this word:
- Trust is situation when you are sure in other party words/deeds

Outside IT you gain trust, it is a process. And you gain it with time when you prove yourself trustworthy. I believe everyone agree that you should trust your cloud provider if you move your data and intellectual property to their premises. Experience is the thing that came right after it was needed.
What we do with our relations with new people and establishing if we can trust them is calling for trusted 3rd party. You cannot be sure if a man or woman right across the table is a real doctor, so you ask for diploma from university you trust.
Unfortunately in cloud provider space there is no trusted authority to certify one or another provider. There are several organizations to help us though, like global Cloud Security Alliance with ready to use questionnaires. You just take it and ask your provider to answer these questions for you.

From other side what I see – most of companies exaggerate importance of their data, because they don’t really have a clue. Netherlands police for example took a deep look into data they have. Guess what they have found – 95% of everything they have is NOT confidential. How much commercial company data is really confidential you think?

What should you do before considering cloud services.
1) Clean up a mess in your internal IT. Cloud is about automation, and when you automate the mess – you get automated mess.
2) Classify your data. There is no need in 100 different types and security classes, 3 to 5 would be just fine.
3) Start with new non-confidential data.
4) Start with new test zone in the cloud.
5) Start with secondary and support processes.
6) Deploy seasonal and peak loads in the cloud.
7) Create and test backup policy with offsite data storage, so if cloud goes down you have at least backups.

DO NOT

1) Replicate your services as they are.
2)Move everything at once, especially business critical applications.

Дизайн VDC. С чего надо начинать

Введение

Информационная система с точки зрения пользователя хорошо определяется в ГОСТ РВ 51987 - «автоматизированная система, результатом функционирования которой является представление выходной информации для последующего использования». Если рассматривать внутреннюю структуру, то по сути любая ИС является системой реализованных в коде взаимосвязанных алгоритмов. В широком понимании тезиса Тьюринга-Черча алгоритм (а сл-но ИС) осуществляет трансформацию множества входных данных в множество выходных данных.
Можно даже сказать, что в трансформации входных данных и есть смысл существования информационной системы. Соответственно ценность ИС и всего комплекса ИС определяется через ценность входных и выходных данных.
Исходя из этого проектирование должно начинаться и брать за основу данные, подстраивая архитектуру и методы под структуру и значимость данных.

Хранимые данные
Ключевым этапом подготовки к проектированию является получение характеристик всех наборов данных, планируемых к обработке и хранению. Эти характеристики включают в себя:
- Объем данных;
- Информация о жизненном цикле данных (прирост новых данных, срок жизни, обработка устаревших данных);
- Классификация данных с т.з. влияния на основной бизнес компании (то триаде конфиденциальность, целостность, доступность) вместе с финансовыми показателями (напр. стоимость утери данных за последний час);
- География обработки данных (физическое расположение систем обработки);
- Требования регуляторов по каждому классу данных (напр. ФЗ-152, PCI DSS).

Информационные системы

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

Модель угроз

В обязательном порядке должна быть в наличии формальная модель угроз, от которых планируется защищать данные / сервисы. При этом модель угроз включает в себя не только аспекты конфиденциальности, но и целостности и доступности. Т.е. например:
- Выход из строя физического сервера;
- Выход из строя коммутатора top-of-the-rack;
- Разрыв оптического канала связи между ЦОД;
- Выход из строя оперативной СХД целиком.
В некоторых случаях модели угроз пишутся не только для инфраструктурных компонентов, но и для конкретных ИС или их компонентов, как например отказ СУБД с логическим разрушением структуры данных.
Все решения в рамках проекта по защите против не описанной угрозы являются излишними.

Требования регуляторов

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

Целевые показатели RPO / RTO

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

понедельник, 30 ноября 2015 г.

VMware User Group 2015-2. Программа

Все меньше времени остается до 8го декабря.
Место проведения Best Western Vega Hotel & Convention Center, Москва.
Начало регистрации 10-00, начало мероприятия 10-30

  • "Docker в виртуальной среде VMware”, Андрей Коновалов, Инфосистемы Джет, vExpert
  • "Правила хорошего тона при дизайне виртуализованного датацентра”, Антон Жбанков, vExpert, Cloud Architect.
  • "Работа с инженерной графикой в VMware Horizon View”, Алексей Худяков, Гипрогазочистка, зам. генерального директора
  • "Secured Horizon View Architecture" Edward Haletky, vExpert, Cloud Security Architect
  • "VMware VSAN как она есть." Николай Куликов, VMware
  • vПроекты 2015 года. Накопленный опыт и практические советы. Владислав Кирилин, VMware PSO, Consultant.
  • “Встроенные средства обеспечения безопасности VMware vSphere. Сухо и комфортно.” Антон Жбанков, vExpert, Cloud Architect.
  • "Плюсы и минусы архитектуры Horizon Cloud Pod." Николай Куликов, VMware
  • "Наши самые интересные проекты. Байки из склепа" круглый стол


Регистрация обязательна.

среда, 18 ноября 2015 г.

VMware Online Technology Forum

Не пропустите технологический форум VMware Online Technology Forum 25 ноября 12:00 – 16:30 по московскому времени. Это бесплатное online мероприятие, где мы расскажем о новых разработках для единого гибридного облака и других технологических новинках, которые при помощи программно-определяемых технологий позволяют вам ускорить внедрение новых приложений и услуг. Мы расскажем обо всех последних решениях и технологиях, включая продукты NSX, vCloud Air и EVO:RAIL. Кроме того, наши эксперты всегда готовы ответить на ваши вопросы в режиме онлайн.
Зарегистрируйтесь сейчас и получите доступ к общению с партнерами в рамках технологических сессий и практических лабораторных занятий. Технические эксперты VMware, среди которых Джо Багли (VP & CTO, EMEA), Дункан Эппинг (главный технолог), Майк Лаверик (архитектор по интеграции продуктов), Дэвид Хилл (старший архитектор по техническому маркетингу vCloud Air) и Питер Бьорк (главный системный инженер), будут рады ответить на ваши вопросы.


Технологические сессии будут посвящены следующим темам:

Гибридное облако: продвинутые сетевые услуги vCloud Air

Мобильность бизнеса: VMware Horizon – улучшение работы Citrix

Программно-определяемый ЦОД: Инфраструктура: управление центром обработки и хранения данных с помощью vRealize Operations Insight 6.1

Программно-определяемый ЦОД: Новые услуги: облачные приложения и контейнеры

Программно-конфигурируемые сети: использование NSX для расширения сети с участием множественных ЦОД

Зарегистрируйтесь сейчас чтобы услышать:
• Аудиодискуссии с экспертами VMware в режиме реального времени с возможностью задавать вопросы и получать ответы
• Наиболее интересные моменты лабораторных с участием создавших их экспертов VMworld
• Технологические сессии, которые вы выберете сами

Присоединяйтесь к нам в среду, 25 ноября!


воскресенье, 15 ноября 2015 г.

Virtual DataCenter Design. Host Sizing. 1

Hyper-Threading

A lot of times I see two contradictory approaches on how to include HyperThreading to sizing. You can just ignore HT at all, and calculate CPU power based on “real” cores, or you can double CPU power because you see twice as much logical CPUs. Unfortunately they’re both wrong. In general you can safely assume HT as +25% CPU, but with some ifs. The main IF is that HT makes most of the efficiency on workloads with a lots of small VMs. Let’s assume we have a dual-way host with 12-core CPUs. That means 24 “real” cores, or 30 “effective” cores. But 24 vCPUs would still be the widest VM you should place on that host.

1 or 2 or 4

Should we choose 2-way or 4-way servers for virtualization? Pretty common problem. So how to solve it?

Target workload is the answer 100% of the cases, and fault domain size. Fault domain in this case is one host. Let’s assume we have a target workload of 200 VMs that can be handled by 10 dual-way hosts with 256GB of RAM each. It’s not a rocket science to deduct that 5 4-way hosts with 512 GB of RAM can handle this workload as well. But! In case of HA event we’ll have double number of VMs affected with services, double number of VMs to restart, increased load on SAN. We have 20% of resources gone from cluster instead of 10% for dual-way servers. And that’ not all, for the planned maintenance we have to evacuate twice as much VMs which leads us to 2-2,5 times more evacuation time.

Latest improvements in CPU design bring us unprecedented number of cores per single socket, making 2-way vs 4-way quarrel even more complicated. Why the hell not 1-way servers with 16-18 cores CPU?

Conclusion. 4-way servers should be used in such cases as:
- Need to use Xeon E7 CPUs instead of E5. But still we can use 4 way servers with 2 sockets filled.
- Need for ultra-wide VMs size of full 2-way server or more, without possibility of application level clustering to split the load.

CPU choice

How to choose CPU in the family – that’s the question. You can try to stick your finger in the sky, use the coin or even a prophecy. But still most of the choices are made without real thinking. Let’s take a view on some basic aspects.
- NUMA. All the current x86 CPUs have the NUMA architecture. So each CPU has it’s own memory instead of globally shared. You have to access another CPU’s memory through the owner which is slower. But that’s not actually the problem, it’s just an issue to consider. Real problem is that you cannot install only half of maximum memory if you don’t install second CPU on 2-way server.
- CPU price, and price per core.
- Software licenses cost.

Let’s assume we chose Intel R1304WT2GS as basic platform for virtualization. So now we should to decide number of CPU to achieve maximum performance / cost efficiency. We are planning to install vSphere Standard ($1940), Windows 2012R2 Datacenter for VMs ($6155 / 2 CPUs) and Veeam Backup Standard ($1116).
Hardware costs $7970 for 1 socket configuration (E5-2670v3 12c + 192 GB), and we need licenses for 1 socket, which would be another $6133 resulting in approx. $14100 total.
2 socket configuration with the very same performance characteristics would cost $6890 (dual E5-2620v3 6с + 192 GB), but software costs double and result is $19160. So with the very same performance characteristics 1-way server is cheaper and a little bit faster due to just 1 NUMA node. Disclaimer – this is not 100% correct calculation, but a mere example of way to calculate.

So why do we need 2-way or even 4-way systems?
- 2 way servers have twice as much maximum memory.
- Single CPU is not enough for really highly loaded applications.
- As a general rule the more cores CPU have – the less is frequency. For an application with core-based licensing such as Oracle DB that can be an issue. For example, 2*E5-2637 v3 (4с, 3.50 GHz) and 1*E5-2667 v3 (8с, 3.20 GHz) have 10% difference in peak performance (28GHz vs 25,6GHz) while core-based licenses would remain the same.

General recommendations:
- Multi-core CPUs are well suited for loads with a lot of lightly to medium loaded VMs. More cores are better.
- The wider VMs are used – the better they perform.
- If you have only a few VMs with applications known for their love for MHz instead of good parallel procession – stick to higher frequency CPUs with less cores.
- Always start you design with single CPU servers. Add second CPU only after a minimum of 5 hosts reached (except of vSphere Essentials) or when you really need more memory that single CPU can support. Or leave second socket for a future upgrade.

пятница, 13 ноября 2015 г.

Дизайн VDC. Сайзинг хостов. 1

Hyper Threading

Часто встречаются два противоположных и неверных утверждения – HT не надо учитывать, и учитывать надо как полные ядра, т.е. умножать на два.
HT при сайзинге следует учитывать как +25% процессорной мощности. Хост с 2 процессорами по 12 ядер и HyperThreading имеет 24 ядра или 48 потоков, что с указанным коэффициентом дает мощность, эквивалентную 30 ядрам.
Следует отдельно отметить, что максимальный размер ВМ в этом случае должен быть не более 24 vCPU. Hyper-Threading дает максимальный эффект на большом количестве ВМ с малым количеством vCPU.

1 или 2 или 4

Выбор между 2х или 4х процессорными серверами под виртуализацию следует делать исходя из типа нагрузки, планируемой для данного конкретного кластера. Ключевой показатель – это размер домена отказа. Т.е. насколько виртуальная ферма и продуктивная нагрузка пострадает от отказа единичного сервера. Предположим, под 200 продуктивных ВМ нам требуется 10 2х-процессорных серверов с 256 ГБ памяти. Очевидно, что их можно заменить 5ю 4х-процессорными серверами с 512 ГБ памяти без потери производительности. Однако это означает удвоенное количество ВМ на сервер, и соотв. двойной объем памяти ВМ в нагрузке. При выходе одного хоста из строя и срабатывании HA мы имеем разницу в два раза по количеству ВМ и продуктивных сервисов в рестарте, увеличенную нагрузку на СХД при рестарте ВМ. А также выход двойного объема ресурсов из кластера – 20% (4х) против 10% (2х). При запланированном простое хоста (под регламентные работы) двойное количество ВМ требуют миграции, что в 2-2.5 раза увеличивает время самой миграции.

С учетом роста количества ядер в процессорах для 2х процессорных серверов, возникает смысл в переходе даже на 1-процессорные серверы.

Итого. 4х процессорные серверы под виртуализацию рекомендуются в следующих случаях:
- необходимость использования иного семейства процессоров (Xeon E7, а не E5) под продуктивную нагрузку. В этом случае 4х процессорный сервер может быть с 2мя установленными процессорами.
- необходимость в размещении сверхшироких ВМ, шириной в полный двухпроцессорный физический сервер или более, при невозможности или экономической неэффективности кластеризации приложения с разделением нагрузки на ВМ меньшей ширины.

Выбор процессора

Выбор процессора внутри семейства затрагивает сразу несколько параметров, которые необходимо рассмотреть.
- NUMA. Все современные x86 процессоры имеют архитектуру NUMA. Т.е. у каждого процессора в сервере есть своя память, и обращение к чужой памяти напрямую невозможно. Иными словами, если в 2х процессорном сервере установлен 1 процессор, то памяти можно установить только половину от максимально возможной.
- Стоимость самого процессора и стоимость в расчете на ядро.
- Стоимость лицензий на системное и прикладное ПО и модель лицензирования.

Предположим, что в качестве платформы выбран сервер Intel R1304WT2GS, и теперь стоит вопрос сколько и каких процессоров в него установить для максимальной экономической эффективности. В качестве ПО предполагается vSphere Standard ($1940), Windows 2012 R2 Datacenter ($6155 / 2 CPU), Veeam Backup Standard ($1116).
Итак, для конфигурации 1xE5-2670v3 (12c) и 192 GB сервер будет стоить в сборе $7970 и потребует по 1 лицензии ПО (лицензирование по сокетам), что дает $6133 за софт или $14100 за сервер.
При выборе варианта с 2мя процессорами E5-2620v3 (6с) стоимость самого сервера уменьшается до $6890, однако стоимость лицензий удваивается и дает $19160. /* расчет не является 100% корректным и призван лишь проиллюстрировать сам принцип
При равной мощности и объеме памяти двухпроцессорный сервер обладает большей ценой (спасибо лицензиям) и потенциально меньшей производительностью за счет 2х узлов NUMA.

Так зачем же нам нужны двухпроцессорные и, тем более, четырехпроцессорные серверы?
- В двухпроцессорном сервере вдвое больше максимальный объем памяти.
- Одного, даже топового, процессора может не хватать по вычислительной мощности.
- Многоядерные процессоры не всегда имеют высокую тактовую частоту, а стоимость лицензий на системное ПО значительно ниже стоимости прикладного ПО, лицензируемого по ядрам. Например 2*E5-2637 v3 (4с, 3.50 GHz) и 1*E5-2667 v3 (8с, 3.20 GHz) имеют 10% разницу в пиковой производительности (28GHz vs 25,6GHz), что может стать решающим фактором для выбора процессоров для нагруженной Oracle DB.

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