?

Log in

No account? Create an account
 
 
15 May 2018 @ 10:33 am
Облака - белогривые лошадки  
За последнее время много вожусь с IaaS-облаком; хочется излить несколько наблюдений, как подходы, принятые в обычных, невиртуализированных системах некритически переносятся в облачную среду:

1. Неоднократно наблюдал, как на облачных серверах баз данных или там Exchange люди привычно ставят диск для баз, и отдельно - диск на transaction logs, думая, что это улучшит производительность. Да с чего бы? На обычном железе в этом был простой, понятный смысл: на диске баз данных считывающая головка может прыгать между секторами как угодно, а на диске логов будет большую часть времени просто записывать в хвост. Соответственно, лучше, чтобы диски были разные.
Но зачем это делать в облаке, где все эти диски - всего лишь файлы на датасторе? Если они хранятся на одном и том же физическом хард-диске - ну так значит, он обречён крутиться псевдорандомально. Но даже если мы разнесём их на разные хранилища - один чёрт каждое из них используется тучей прочего народу. Предсказать, как реально будут крутиться хард-диски в этих хранилищах - абсолютно невозможно.

Впрочем, по мере ухода магнитных дисков этот вопрос отпадёт окончательно. Хотя и тогда по инерции админы будут разносить базы и логи - у нас так заведено.


2. Продолжая тему дисков - объясните мне кто-нибудь, а какой смысл в локальных дисках в облаке? Почему не определить любой, или хотя бы любой data disk как shared? (Шишков, прости...) Это в физическом мире у нас есть либо SAN, либо просто SCSI-кабель к дискам, который больше чем в один компьютер не воткнёшь. А в виртуальном какая разница, какое устройство эмулировать - SCSI-контроллер или HBA какой-нибудь? Один чёрт наши диски - просто файлы на каком-то датасторе.

Сегодня облака shared disks обычно не предоставляют, и поэтому, чтобы завести какой-нибудь кластер на виртуалках, который их требует (да хотя бы файлсервер на микрософтовском Failover Cluster) нужно сооружать дикие турусы на колёсах. А как было бы просто: кликаешь в облачном портале мышкой пару раз - вот тебе виртуалка с диском. Кликаешь ещё - вот тебе вторая, третья, восьмая виртуалка, и все видят тот же диск. А дальше дело твоё, как их координировать: либо только главный сервер кластера юзает диск, либо ставь файловую систему, поддерживающую доступ со многих, типа VMFS или GFS2.


3. VLANs и, шире говоря, Ethernet вообще. Как-то упускается из виду, что в обычных локальных сетях broadcast domains существуют не от хорошей жизни, а оттого, что каждый компьютер в порт файерволла не воткнёшь. Хотелось бы инспектировать трафик между любыми двумя хостами - но что делать, свитчи функциональностью современного файерволла не обладают, а если такие и есть, то цена у них заоблачная, pun intended. Поэтому, если не хочется угробить производительность, приходится разбивать сеть на какие-то секьюрити-зоны, отказываться от возможности фильтровать трафик внутри них и удолетворяться фильтрацией между ними. Кроме того, VLAN-ы позволяют с лёгкостью гонять групповой и широковещательный трафик.

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

Пример: допустим, у меня классический расклад - 20 вебных фронтэндов, за ними SQL Server. По логике секьюрити-зон, мне надо засунуть фронтэнды в один VLAN, SQL - в другой, и контролировать трафик между ними. Но тогда фронтэнды могут между собой неограниченно общаться - а зачем мне это надо? Им нужно говорить с HTTP-клиентами и с SQL-сервером, а друг дружке им что-либо передавать незачем.

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

Надо сказать, что Микрософт это как раз осознали - в Azure классического Ethernet-а нету, они там наворотили что-то своё на Layer2. В результате можно фильтровать трафик между любыми машинами, даже если они сидят в одном сабнете - но любой неюникастовый и, шире, любой не-IP трафик не поддерживается. По-моему, выбор в правильную сторону.


А у вас какие наблюдения?
 
 
Current Music: Joni Mitchell - Clouds
 
 
 
vladimir000: pic#86263431vladimir000 on May 15th, 2018 07:54 am (UTC)
> Впрочем, по мере ухода магнитных дисков этот вопрос отпадёт окончательно. Хотя и тогда по инерции админы будут разносить базы и логи - у нас так заведено.

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

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

Другое дело, что если все виртуальное, то смысл разделения теряется.
Кот Муцийcat_mucius on May 15th, 2018 09:52 am (UTC)
И ты тоже прав - этот совет Микрософт давали из обоих соображений. :-)

Другое дело, что если все виртуальное, то смысл разделения теряется.
Именно что.