Ограничивать ли пользователей по ресурсам?

Сколько я занимаюсь ИТ - столько я слышу от админов "больно жирно будет пользователям, обрежем им трафик / объем почтового ящика / файловую шару / заблокируем сайт / подставить по вкусу". И ровно столько же у меня возникает вопрос: какое ваше дело?
Давайте забудем, что мы ИТ-шники и управляем клевыми СХД, фермами серверов, поточвыми серверами и посмотрим на всю это катавасию отстраненно. Рассмотрим коммерческую структуру.

1. Чем занимается ваша компания?

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

2. Кто производит деньги?

А их производят те самые "тупые юзвери", которые просят нажать any key великого и могучего техномага. Даром что техномаг настолько велик, что не может читать инструкции на английском (рабочем языке ИТ), а для русского он и так слишком велик.

3. При помощи чего они производят деньги?

Деньги производятся в том числе при помощи ИТ сервисов, включая почтовые серверы для коммуникации с клиентами, интернета, систем учета, бухгалтерии и т.д. В процессе производства денег ИТ сервисы потребляют ИТ ресурсы - сырые мощности (процессоры / ОЗУ / СХД), лицензии, каналы.

4. Кому принадлежит ИТ инфраструктура и ресурсы?

Вот здесь раз от раза я натыкаюсь на то, что администраторы начинают считать серверы, СХД и коммутаторы "своими". Даже немного, и начинают относиться к ним соответственным образом.

Правильный ответ: они принадлежат компании (владельцу компании) и должны исполнять свою задачу по генерации денег.

5. И теперь - кто должен решать, сколько ресурсов может потребить сотрудник бизнес подразделения?

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

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

Вы конечно можете возразить сразу по нескольким пунктам. Давайте их рассмотрим.

1. Если не ограничивать соц. сети, то вместо работы все будут только во вконтактике сидеть.

Может быть. Но разве это ваша сфера ответственности и знаний? У сотрудника есть начальник, который оценивает качество его работы. Может быть, конечно, именно начальник попросит обрезать Ивану Ивановичу Иванову доступ к соц. сетям - но это его сфера принятия решения. Может быть это будет политика ИБ, но опять же, это не решение админа.

2. Они безмозглые и ничего не понимают в ИТ. И совсем не думают, что их смешные картинки и видюшки в почтовых вложениях полностью съедят СХД под почту.

Ну на то и есть вы, мозглые и понимающие. Только вот есть снова интересный момент, ничего не воспитывает человека так быстро и эффективно, как воздействие на его кошелек. Один раз остаться всем отделу маркетинга без премии потому что они 90% потребленного пространства в почте потратили на картинки - и их компьютерная грамотность / здравый смысл резко повысятся. А самое главное, стимулировать их повышение будет родными и понятными методами начальник отдела, оставшийся без премии. Вся их премия уйдет на расширение СХД.

3. У нас в ИТ ограниченный бюджет и мы не можем позволить им есть ресурсов сколько они хотят.

Позвольте, но это классический пример "административная проблема техническими средствами не решается". Проблема с планированием бюджета / экономическим обоснованием закупок в классической модели - это административная проблема на уровне директората, а не админа. Более того, при помощи биллинга вопрос обоснования бюджетов решается сильно проще.
Есть и другая сторона ограничения ресурсов. Вы перестаете контролировать что происходит в компании. Пользователи начинают удалять важную на самом деле почту, потому что новую не могут получить. Важные документы оказываются в облаках, переписка перемещается с корпоративной почты в Яндекс и Мейл.ру. Иными словами, именно слепой репрессивный метод является создателем "теневого ИТ".

И да, это все я рассказываю с 2014 года. "Департамент ИТ против частного облака"

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.

Безопасность - это не только конфиденциальность. РусКрипто 2016.

Безопасность - это не только конфиденциальность from Anton Zhbankov

"IT vs Private Cloud" Paradox

Many years we speak of cloud computing, and I have been selling private cloud for a long time. But we’re still in very early stages of private cloud adoption. Why?

Answer was a surprise even for me. Private cloud is not something IT department need.

Every commercial company is a manufacturer. Yes, I’m not mistaken. Even small nail salon is a manufacturer. They produce profit. Just for argument simplicity let’s talk about profit as income minus costs (capital expenses and operational expenses including salaries). As we know dollar saved is dollar earned and therefore we’re driving costs down.
But where does cloud part come in you ask? Just wait for it.

Let’s take a look at allegedly most interested in cloud employees – IT department. Department includes IT management and administrators / specialists, IT assets in both hardware and software. And budget. As a rule, IT budget looks like some kind of financial black hole actively consuming sums with many zeroes. It’s almost impossible to understand financial flows and how it reflects on actual IT services. Here comes private cloud with financial visibility, service catalogs and measured service – so we can actually say how much one mailbox costs. We’re in CFO dream now.

But IT department says: NO!
RLY? WTF?

Ok, let’s take another look on IT department, completely unrelated to technology – motivation.

What average IT admin wants? Pretty simple answer: high-tech toys, arcane techno mage status and significance. Who should choose new servers/storage system? Of course ME, it’s MINE! No, it’s not. It’s a tool, not a toy, and cloud brings us standards for systems. More than that, cloud makes admin interchangeable, the role does not bear any arcane knowledge anymore. Cloud admin is highly qualified in several areas – yes, but I don’t really see a lot of admins after 30 who really want to study something new and adapt. People want stability and “expert” title. What they do not want is to remain students till grandchildren.

What does IT management want if we skip part with kickbacks and gray schemes on procurement? Pretty the same – influence and significance. Which directly translates to number of employees and total systems cost. Plus a budget to control themselves, with no one looking over the shoulder. Each new new employee reporting bring costs, and each new admin add NO to the cloud question.

What cloud makes with IT budget? Black hole splits into separate services with measured costs, and CFO can now compare internal services with available on the open market. Which can be not in internal services favor. Cloud brings financial visibility to financial management and line business managers as well as how to spend budget in accordance with company targets.

-       What, board will be able to see how I spend my budget?! – direct quote from one CIO I met.

It’s not a paradox, we now understand why IT don’t like cloud. But what should we do? I don’t have that answer.

Департамент ИТ против частного облака

Департамент ИТ против частного облака from Anton Zhbankov

Какой же язык программирования самый облачный?

Данный пост навеян обсуждением в Фейсбуке, начавшимся с "на JS и PHP написаны все говнооблака спорить не буду. А что потом? Так вот, за F# будущее".
В процессе обсуждения была высказана интересная мысль, даже смелая: "Облако - это новая вычислительная среда. Она устроена действительно по-иному нежели привычные нам персоналки".
И вот в чем вся соль: оба этих утверждения неверны.

Облако - это прежде всего самообслуживание и биллинг, это непременные атрибуты XaaS. Внизу облачный сервис состоит из множества маленьких сервисов, подсервисов и подсистем, каждая из которых может быть написана на любом языке или даже смеси языков. На некоторых языках программирования удобнее писать определенный вид сервисов. И то, если у вас есть команда разработчиков, хорошо владеющих данным языком и всей обвязкой к нему в виде библиотек и импортируемых модулей.
Я лично назвал бы только два с половиной языка, на которых можно написать полный стек облачного сервиса - это C, C++ и Java. Во всех остальных случаях придется использовать несколько языков. Но удивительное дело, ни один из них не нов и ни разу не облачен.

Вернемся ко второму утверждению о принципиально новом устройстве облачной среды с точки зрения программирования.
Как только мы отбрасываем биллинг и самообслуживание в PaaS, то оказываемся в совершенно традиционной среде, существовавшей задолго до облаков, хотя может быть и не столько популярной. И называется она Grid. Ничего нового облака нам снова не принесли, кроме значительной популяризации архитектуры грида. Возьми любое популярное PaaS облако, как например AWS или Azure - это не более чем набор очень больших гридов на каждый сервис и API к ним. API, кстати, тоже совсем не облачное изобретение.
Впрочем, есть пожалуй одна из архитектурных концепций, зародившихся примерно одновременно с облаками. Хотя я бы поставил ее как основу облаков, а не их следствие. Архитектура, построенная по принципу Design To Fail, или по-русски рассчитанная на отказ. Классическая привычная нам архитектура монолитных систем высокой доступности не может масштабироваться, и по сути ограничена сверху размером хоста. Для Scale-Out, неограниченно масштабируемой горизонтально системы, требуется не высокая доступность, а способность переживать отказ части узлов грида с минимальными последствиями для жизни всей системы.

Итого:
1. Нет никаких "облачных" языков, есть лишь универсальные и специализированные. Облако может быть построено на любом универсальном или любом миксе специализированных языков программирования.
2. Облака ничем не отличаются по архитектуре от дооблачных сервисов, несмотря на значительное развитие и появление новых сервисов в облачную эпоху.

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.

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, если департамент ИТ просто предоставляет отчет о потребленных ресурсах различными линиями бизнеса. Причем ключевым моментом является приведение мегабитов к рублям.

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

vSphere 5.1 vs Hyper-V R3. Оценка стоимости ресурсов.

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

То есть вместо того, чтобы платить за фиксированные ресурсы - количество ЦПУ, объём памяти и объёмы ГБ на СХД пользователь платит только за количество реально использованных мощностей поставщика - количество гГц, количество IOPS и утилизированную память. Основываясь на этих данных облачный провайдер уже может выставить счёт заказчику.

Hyper-V
Сам гипервизор позволяет измерять количество гГц, объём занятой памяти, количество переданной по сети информации и объём диска ВМ, но не позволяет считать количество IOPS, что тоже было бы неплохо.

Hyper-V не имеет какого-либо графического интерфейса для составления отчётов, управления стоимостью ресурсов, и т.д. Для создания отчёта об использовании ресурсов необходимо использовать скрипты на PowerShell, а отчёты потом импортировать в соответствующее ПО.

System Center Service Manager 2012 SP1
Оценка стоимости утилизации ресурсов реализована в специальном дполнении Center Cloud Services Process Pack для System Center Service Manager 2012 SP1.

vSphere
VMware предлагает отдельный продукт - vCenter Chargeback Manager, который позволяет считать самые разнообразные параметры и автоматически выставлять счета.

Построение кластеров. Clouds NN 2012

23-24 августа я выступал на Clouds NN 2012 с темой "Как строить геораспределенные облака". Получилась, на мой взгляд, отличная презентация на тему видов кластеров.

* Для управления необходимо кликать по слайду, или жать пробел - слайды с анимацией.

Облака и RCCPA

Мы сделали это!

В России создана Russian Cloud Computing Professional Association (RCCPA) – первое профессиональное объединение независимых экспертов, работающих в области создания, развития и внедрения «облачных» технологий и сервисов. Ассоциация создана в марте 2012 года группой активистов «облачного» рынка. Наши основные цели - выработка единых подходов к формированию развития «облачных» вычислений в России и формирование экспертной площадки для развития российских “облачных” проектов на международных рынках. В планах ассоциации – регулярное проведение встреч, семинаров и конференций, в рамках которых члены ассоциации смогут обмениваться опытом по профильным вопросам.  Мы открыты для сотрудничества, членство и участие в мероприятиях ассоциации бесплатно.

Ждем вас в ассоциации - специалистов по дизайну виртуализованных инфраструктур, превращению железа в облако и продажам облачных услуг. Приходите на CloudConf 2012, где мы будем вручать первую в России премию за достижения в облачных вычислениях - Cloud Award 2012. Ну а я буду участвовать в зажигательном круглом столе "Облачная жесть как она есть" и рассказывать об особенностях облачного хранения данных.

А в этом блоге появляется новая тематика: облака :)

И в качестве начала новых, облачных дискуссий, предлагаю вашему вниманию перевод стандарта NIST по облачным вычислениям. Замечания и критика приветствуются!

Новый облачный учебный курс и сертификация от EMC

Компания EMC добавила в облачный трек Cloud Architect новый учебный курс и сертификацию базового уровня по облакам.

Напомню, что ранее для сертификации по программе EMCCA в качестве базового уровня (Associate) требовался общий курс по управлению информацией EMCISA (E20-001 - Information Storage and Management). Курс безусловно полезный, однако к облакам имеющий отношение отдаленное. Теперь появились специализированный базовый облачный курс Cloud Infrastructure and Services и сертификация EMCCIS (E20-002).

Предполагаемые темы вопросов экзамена EMCCIS:

Journey to the Cloud and Cloud Primer
• Business drivers and characteristics of Cloud
• Phases and activities of journey to the Cloud
• Cloud deployment and service models
• Cloud benefits and challenges
Classic Data Center
• RAID Technology and intelligent storage system
• Storage Networking options: DAS, FC and IP SAN, NAS, FCoE, and unified storage
• Backup and Replication
• Data Center management in classic environment
Virtualized Data Center
• Compute virtualization
• Storage virtualization and virtual provisioning
• Network virtualization including virtual LAN and SAN
• Desktop and application virtualization
• Business Continuity in a virtualized environment
Cloud Services and Management
• Cloud infrastructure, service creation and management
• Cloud security concerns, solution, and best practices
• Best practices and consideration for migration to the Cloud

Помимо этого появился учебный курс высшего уровня Expert (EMCCAe) - IT-as-a-Service Planning and Design, однако экзамен на этот уровень ожидается только в феврале 2012.

This expert-level course provides the knowledge and skills necessary to design cloudbased IT-as-a-Service (ITaaS) solutions. Building on the skills acquired in the Virtualized Data Center and Cloud Infrastructure specialist-level course, it focuses on business, organizational, governance, technology, and service management aspects from a designcentric perspective. By utilizing lecture, discussions, case studies, design examples, and a series of interactive problem-solving labs, students will learn to design solutions which transform business operations and virtualized data centers into ITaaS environments. The course is applicable to enterprise, service provider, and existing virtualized data center operations considering ITaaS. This course uses an open approach focusing on core concepts, principals, and technologies rather than specific products. To provide context, the course includes EMC specific examples and case studies.

EMC Cloud Architect

Коллеги, хочу поделиться впечатлением от курса Virtualized Data Center and Cloud Infrastructure, который прослушал месяц назад в рамках программы Cloud Architect.

Общее впечатление: настоятельно рекомендую всем, кто занимается/интересуется чем-то большим, чем простое администрирование платформы виртуализации.

А теперь подробнее. Насколько мне известно (хотя конечно могу и ошибаться), это один из первых курсов, предлагающих обучение по облакам в целом. При этом акцент именно на облаках, на определении и концепции. Чем облачный сервис отличается от не облачного?
Это НЕ технический курс и он НЕ о том, какие продукты должны лежать в основе облака. Поскольку курс от EMC, то в качестве примеров разумеется используются продукты EMC и VMware, но упоминаются достаточно поверхностно, лишь в связи с тем, что они обеспечивают - Data Mobility, Resource Pooling и так далее. Технари, ожидающие детального "вскрытия" облака и тонкой хирургии в его внутренностях, скорее всего будут разочарованы. Я тоже сначала слегка был.
Однако суть курса не в этом, продуктовые курсы с тонкой настройкой и скрытыми параметрами в конфигурационных файлах вы всегда можете взять отдельно. Для 100% технаря вроде меня данный курс полезен тем, что позволяет уйти от техники к концепции облака, от мегагерцев к услугам, к уровням обслуживания.

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

Курс предполагает сертификацию EMCCA (E20-018 Virtualized Data Center and Cloud Infrastructure Design Specialist) - уровень EMC Proven Professional Specialist. Для сдачи экзамена необходима базовая сертификация EMCISA (E20-001 Information Storage and Management).

Обратная сторона "облака" - презентация

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

Обратная сторона облака

Обратная сторона "облака"

Хочу сообщить, что 1го июля в Москве CNews Conferences и CNews Analytics проводят круглый стол «Управление непрерывностью бизнеса: лучшие ИТ-решения».

Я там буду выступать с докладом "Обратная сторона "облака", и расскажу то, о чем вендоры вам не хотят говорить.

VMware покупает Zimbra

Alessandro Perilli сообщает, что сегодня, 12 января, VMware должна подтвердить слухи и официально объявить о покупке Zimbra у Yahoo.

Что такое Zimbra? Это пакет для коллективной работы (collaboration suite), включающий так же в себя бесплатный мультплатформенный e-mail клиент. Ближайший аналог для сравнения - Microsoft Exchange.

Чем это грозит в будущем? VMware из производителя ПО для виртуализации превращается в провайдера услуг, и в частности будет конкурировать на этом поле с Google.

Интересное сравнение провел Mike Hogan (Microsoft - оранжевый, Oracle - красный, VMWare - зеленый, и IBM - подождите... а вот он - голубой).

В связи с чем возникают вопросы:
1. Нужен ли VMWare собственный Linux (как например Novell’овский Suse)?
2. Какую СУБД включит в свой пакет VMware? Сейчас есть варианты с открытым кодом - MySQL, Postgres и Ingres.
3. Пойдет ли VMWare дальше, до высокоуровневых приложений как Zoho, SugarCRM, etc.?
4. Будет ли VMWare развивать партнерство с SAP для предоставления уровня приложений и будет ли все это работать в стеке виртуализации?

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

Что это, новый путь эволюции VMware или просто попытка выжить в мире, где Microsoft превратила виртуализацию в атрибут обычной ОС, а Google уговорила весь мир принять HTML5 и выпускать просто веб-приложения?

Тема облаков раскрыта!

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

Smart Cloud

И раскрывая тему облаков, более строгое определение их типов:

Software as a Service (SaaS) - Программное обеспечение как сервис.

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

Platform as a Service (PaaS) - Платформа как сервис.

Если Вам нужна операционная система Линукс, или веб-сервер, или вы хотите построить свой продукт на основе систем управления базами данных Oracle или MySQL, Вам необязательно подбирать аппаратное обеспечение, устанавливать и настраивать программы. Услуга "Платформа как сервис" предоставляет возможность гибкого и широкого выбора настроенных под Ваши задачи виртуальных вычислительных ресурсов. Одним из примеров может служить доступ к виртуальному Windows XP с установленным на нем офисным пакетом.

Infrastructure as a Service (IaaS) - Инфраструктура как сервис

Услуга "Инфраструктура как Сервис" предназначается тем пользователям, которым нужны мощные вычислительные ресурсы. Последние, как правило, стоят больших денег - не только при покупке, но и в обслуживании. Виртуальная инфраструктура позволяет съэкономить на аппаратном обеспечении и на услугах IT (например, администрирование серверов, арендная плата за место, электричество итп). Также данная услуга расчитана на масштабируемость вычислительных ресурсов, например, количество оперативной памяти, процессоров, дискового пространства можно изменять буквально на лету. Одной из разновидностей IaaS стала услуга Data Storage as a Service (dSaaS) - Хранение данных как сервис. Самыми известными представителями IaaS и dSaaS на сегодняшний день являются Elastic Compute Cloud (EC2) и Simple Storage Service (S3) компании Amazon LLC.

http://smart-cloud.ru/faq/31-general/52--cloud-computing

Облака - белогривые лошадки

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

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

Облако - это тот уровень абстракции, который необходим для воплощения понятия computing as a service, он же utility computing. На облачном уровне у нас больше нет сервера1, сервера2 и т.д... У нас есть объединенные вычислительные ресурсы, которые мы можем как-то делить между задачами.

В принципе, облака можно разделить на два типа - облака для приложений и облака для машин. В чем же между ними разница?

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

Облака для машин предоставляют ресурсы виртуальным машинам, и по сути являются более низкоуровневыми облаками или в каком-то смысле менее облачными :)
Атомарная единица здесь не приложение, а виртуальная машина. На которую можно установить любую ОС и вообще обращаться как с обыкновенным сервером.

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

Простейший пример подобного облака - большой Fully automated DRS кластер ESX. Но при одном условии - каждая ВМ требует ресурсов, значительно меньших, чем ресурсы одного хоста. Как только уровень ресурсов становится сравним, облако рассеивается на отдельно стоящие хосты.

Облака - это не пустое понятие, у нас с вами уже есть в серверных свои собственные маленькие белогривые лошадки :)