greefon

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

Дельта при том, что частота смены поколений сотовых сетей существенно меньше, чем частота смены трубок.
Следовательно причина смены трубки целиком не коррелирует с необходимостью смены радиомодуля.
Следовательно даже поменяв модуль 3G на LTE вы в скором времени будете менять и другие модули.

Честно говоря, мне очень сложно это понять. Не думаю, что апгоейд оперативки вас сильно выручит при переходе на новую версию ОС. Ну и платить. Больше денег чтобы НЕ пользоваться чем-то — это уж совсем ;)

Если я правильно помню, в Москве 3G заработал в 2008 году. LTE в 2014. Дельта — 6 лет. Сколько телефонов вы сменили за это срок?

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

Ниче. Он сейчас подсуетится и выпустит такой девайс первым. Самсунг еще не знает зачем, но выпустит.

Если производитель будет поддерживать какой-то минимальный набор модулей

напомню, что

Платформу будет выпускать сам Google, а модули — сторонние компании.

Производитель чего? Что значит «поддерживать»?

продукт прежде всего для тех, кто способен установить драйвер и повозиться с настройкой

Прежде всего? Будут еще пользователи неспособные? Для них сервисы откроют по типу шиномонтажа?! :)

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

Точно. Взял и вставил. Но сначала скачал драйвер. А перед этим обновил ОС, драйвер плохо работает со старой версией. А новая версия тормозит. Ну не беда, поменяем модуль памяти. О, стало клево. Только почему мой новый крутой модуль беспроводной передачи данных работает так же медленно как и старый? Что, проц не успевает? Поменяем! Ой, а для нового типа проца (тут недавно 128бит появились) новый базовый модуль нужен. Ну ладно, теперь заживем. Только не долго, энергопотребление великовато, поменяем еще и батарейку.

Как то так?

Мне, простите, аж дурно стало при мысли об аналогии с апгрейдом PC. Спасибо, не надо.

И дешевле оно никак не окажется.

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

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

Сейчас в SoC «упаковывается» практически все, это и процессор и WiFi и GPS и сотовый модуль и т.д. В перспективе, все функции в одном чипе. Тут предлагается разбить на несколько модулей. Т.е. устройство или станет больше или будет менее функционально.

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

И все это зачем? Чтобы слупить побольше денег на продаже модулей.

1. Вы о чем-то глубоко своем поете, и, может быть в силу своей врожденной тупости, я вас не понимаю.
3. Не пойму с какое мое или свое или еще какое-то утверждение вы пытаетесь оспорить.

1. Хорошо, упростим задачу, если никак не доходит. Если bandwidth на обоих контроллерах на 80%, насколько упадет производительность после перехода на один? Детсад какой-то.
3. Я на кой вы мне это рассказываете? Я в курсе как устроены RAID-5 и RAID-DP

Читайте полностью написано, прежде чем отвечать
habrahabr.ru/company/croc/blog/208784/#comment_7233034

Про излишне слащавую подачу материала соглашусь.
Сейчас у EMC уникальная фича — VMware :) Если серьезно отвечать — то опять же оффтопик будет.

На всякий случай еще прокомментирую, чтобы не было разночтений:
— понятие «Диагональности» относительно RAID5,6 и RAID-DP отличается (в одном случае диагонально расположены блоки четности, в другом случае диагонально рассчитывается четность)

1. Если я что-то превратно понимаю, поднимите мне веки :) Еще раз, постановка задачи. Если оба контроллера в 2х контроллерной системе загружены на 80%, то как один оставшийся (вдвое меньше портов и мозгов) сможет дать 160% производительности.

3. можете дать ээ прфулинк? Я могу

The next level in the evolution of RAID data protection is RAID Double Parity, or RAID-DP (an implementation of RAID 6), available on the entire Network Appliance data storage product line.

Ранний документ
www.netapp.com/us/system/pdf-reader.aspx?m=3298.pdf&cc=us

NetApp introduced double-parity RAID, named RAID-DP, in 2003, starting with the Data ONTAP® 6.5 architecture.

И новый
communities.netapp.com/docs/DOC-12850

Вы понимаете какая штука, в обычном RAID5 четность как раз диагональная. И в RAID6 тоже. А вот в RAID-DP она смешанная, есть типичная для RAID-4 (на отдельном диске) и дополнительная (диагональная), которая считается со всех дисков RAID-4, включая диск четности.

Так что можете ткнуть инструкторов ответно.

4. Еще раз, приверженность бренду — вопрос пристрастий. Я знаю ендюзеров, которые кроме EMC ничего видеть не хотят. И аргументируют свою позицию.

Выпейте новопасситу. Это не было оскорблением или издевкой. И NetApp является софтовой компанией (торгуется на бирже как софтовая компания).

1. Не совсем понял замечание. Если у нас AA (пусть и не настоящий, а через ALUA) и контроллеры (процессор) нагружены, скажем, по 80%, то при выходе из строя одного из них второй, после файловера, не сможет дать 160% производительности. Конечно, в большинстве сценариев, нагрузка упирается в бэкенд, но случаи разные бывают

3. Про DDP можно отдельную статью написать, но тут, как я уже говорил, несколько оффтопик. RAID-DP это все же двойная четность (DP — double parity), диагональная из них только одна.

4. и PS. как поклоннику NetApp, софтовой компании, вам должно быть очевидно: «полный редизайн» может затронуть только софт (или его идеологию). Появление блочной дедупликации, стремление сделать «честные» снапшоты — явно не косметика. По поводу предпочтений спорить не буду, у каждого свои. Сам я не испытываю антипатии практически ни к одному вендору (с инженерной точки зрения), с маркетинговой точки зрения — может быть. Но вы должны понимать, что не мы являемся целевой аудиторией этого маркетинга.

именно

community.emc.com/docs/DOC-24278

Thick LUN:

When a Thick LUN is created, the entire space that will be used for the LUN is reserved; if there is insufficient space in the Pool, the Thick LUN will not be created. An initial allocation of 3 GiB holds metadata and user data, and as users save additional data to the LUN, 1 GiB slices will be allocated as needed. These slices contain 1 GiB of contiguous Logical Block Addresses (LBAs), so when a slice is written for the first time, it will be allocated to the Thick LUN. Since tracking happens at a granularity of 1 GiB, the amount of metadata is relatively low, and the lookups that are required to find the location of the slice in the Pool are fast. Because lookups are required, Thick LUN accesses will be slower than accesses to Traditional LUNs.

Thin LUN:

Thin LUNs also allocate 1 GiB slices when space is needed, but the granularity inside those slices is at the 8 KiB block level. Any 1 GiB slice will be allocated to only 1 Thin LUN, but the 8 KiB blocks will not necessarily be from contiguous LBAs. Oversubscription is allowed, so the total size of the Thin LUNs in a Pool can exceed the size of the available physical data space. Monitoring is required to ensure that out of space conditions do not occur. There is appreciably more overhead associated with Thin LUNs than with Thick LUNs and Traditional LUNs, and performance is substantially reduced as a result.

Итого, в случае thin блоки 8KB внутри слайса не обязательно идут подряд. Это называется фрагментация, нет?

Эээ, давайте так, старый VNX:
— Thick тома, место резервируется но не выделяется. Выделение происходит при записи, блоки (слайсы) по 1ГБ. Блоки при этом непрерывные (в терминах LBA).
— Thin тома не резервируются при создании. Пространство так же выделяется слайсами по 1ГБ, но эти слайсы не являются непрерывными, и фактически выделение происходит фрагментами по 8KB
— начиная с какой-то версии ПО (не помню точно) Thick тома стали выделять сразу при создании.

C новым VNX все тоже самое, только размер слайса стал 256МБ

Да, так и есть, размер slice 256МБ, значит и пространство в пулах будет выделяться кусками по 256МБ (для thick LUN). Что, в целом, не меняет сути вопроса, разница в выделении пространства кусочками по 8KB и 256МБ достаточно велика.

1. полный AA (full-mesh) или SAA (symmetric active-active) это не только 3PAR. У IBM были эксперименты с XIV, довольно интересная архитектура у SVC (хотя они скорее AAA, но это тема отдельного разговора) решений. Тот же EMC имеет в арсенале богатый опыт с Symmetrix, хотя это хай-енд, ну и про IBM 8xxx, HP XP и т.п. тоже можно упомянуть. На самом деле, необходимость в SAA при наличии таких вещей как ALUA возникает в среднем сегменте не так чтобы очень часто. Тем более, что на многоконтроллерных системах разумно выбирать такую мощность контроллеров, при которой СХД сохранит приемлимую скорость в случае возникновения failover (да, это двухкратное резервирование в случае двух голов, но диски все равно дороже встанут). 3PAR же как система пришел из мира телекома, где требования к стораджу довольно специфические. Так что идеальным решением для обсуждаемой ниши я бы его не назвал.

2. WAFL по своему хороша, но опять же вовсе не идеальна. Она, безусловно, дает много приятностей с точки зрения «правильных» снапшотов, но вот дедупликация на ней так же приводит к снижению производительности на запись (порядка 8-9%). Если вам нравиться WAFL — можете расширить сознание изучением стораджей с ZFS, например.

3. Потому и разделять, что с дополнительным функционалом производительность блочного доступа у EMC проседает. Это не плюс и не минус (очевидно, что чем больше логики, тем ниже производительность). Плохо то, что не все плюшки доступны для пулов. Хотя ниже человек отписал, что этот функционал будет добавлен. Т.е. железку выпустили с несколько недоделанным софтом (возможно не успевали оттестировать). Не понял, что вы имеете ввиду под DDP. Если Double Disk Parity, он же RAID DP в реализации NetApp, то он совсем не RAID60 по внутренней логике. Если же Dynamic Disk Pools, то непонятно при чем они тут вообще.

4. Да, архитектурно у EMC VNX до сих пор остаются спорные моменты, но приятно, что СХД не бросили а продолжают развивать, пусть и ценой полного редизайна. Надеюсь, когда-то мы увидим действительно unified систему без разделения на модули.

Можно конечно. На самом деле, как справедливо догадался Hayz, я в общем-то знаю ответы на свои вопросы. И меня интересует в основном две вещи: знает ли их интегратор/представитель вендора, и почему не говорит.

Смотрите, нам от лица интегратора показывают «игрушку» и говорят: «Смотрите какая красивая, лучше прошлогодней, в ней есть настоящий Active-Active, есть дедупликация, оптимизирован софт, бегите и хватайте. А что по факту?
1. Текущая лучше прошлогодней, потому, что по сути не имеет к ней никакого отношения в плане архитектуры (со слов рассказчиков выше). Почему не получилось развить существующую архитектуру, сохранив приемственность? Потому, что он неудачная? А на момент анонса говорили совсем иные слова. А что там с новой архитектурой?
2. В новой архитектуре есть дедупликация. При включении дедупликации LUN превращается в thin, а значит при алокации блоков они будут выделяться пачками по 8KB вместо 1GB (что медленно). Сам процесс дедупликации проходит online, а не inline, блоки по 4KB, значит во время „уборки мусора“ остануться „дырочки“ (спасибо, что мусор убирают „пачками“ из блоков, как обещается. а если не получается убрать крупным?), которые будут заполнены в последствии другими маленькими блоками. Это приведет к дополнительному падению производительности. На сколько? Или не приведет? Никто толком не отвечает.
3. Вдруг выясняется, что разрекламированный Active-Active работает только на обычных RAID группах, не на пулах. Что случилось? Почему? Объяснение отсутствует. Типа на пулах оно не нужно, потому что не нужно.
4. Думаю, что если поковырять как следует, можно найти еще несколько интересных умолчаний.

пусть не до конца, пусть хотя бы чуть чуть :)

Active-active работает на классических LUN'ах только. Опять же, потому что классические луны используются в основном под приложения, которым требуется более высокий performance.

Какое отношение к выравниванию нагрузки на контроллер имеет тип «диска» (классический или из пула). Почему в одном случае AA работает, а в другом нет. Почему вы говорите о «performance»? Балансировать нагрузку к 500 относительно медленным лунам менее важно чем к 5 быстрым?

Если вы даете дополнительный комментарий «от себя» к документации — будьте добры выражаться полнее.

Вы:

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

Крок:

Новая блочная дедупликация. Принцип старый как мир: данные бьются на блоки, одинаковые блоки хранятся один раз. Для дублирующихся блоков используются ссылки на те же блоки как в архивах. Теперь всё это очень сильно «заточено» под виртуальные среды.
…
Два наиболее типичных типа нагрузки максимально выигрывающих от нового механизма:
Однотипные виртуальные среды, например VDI.
Множественные применения для одного набора данных.

Вы не отрицаете того, что для VDI нужна производительность. Тем самым вы фактически утверждаете, что дедупликация не подоходит для VDI.

Я надеюсь, что вы сознательно уклоняетесь от ответа на вопрос. Иначе придется предположить, что вы его не поняли.

VDI не требует производительности?

Вот не понял логики. Вроде AA нужен для того, чтобы равномерно загружать контроллеры. Причем тут классические луны и какие-то там приложения?

Ага. А почему ваши партнеры (Крок) говорят о дедупликации в применении к VDI? Это не похоже на «библиотеку».

А на остальные вопросы ответить забыли?

3. Имелось ввиду использование старых полок с данными под новыми головами. Такой возможности по прежнему нет, т.е. для миграции нужно хранилище «посредник» + перенастройка

Про остальное уже ответили выше, лучше прокомментируйте лучше вот это

Выглядит это так, словно не из «хорошей» системы сделали «отличную», а совсем наоборот — старая система была так плоха (архитектурно), что понадобился полный редизайн. Ну не суть.

Насколько я понял, при включении блочной дедупликации LUN автоматически становится thin. На старых VNX это приводило к значительной потери производительности. А помимо потери производительности, приводило еще и к фрагментации. Добавление поверх этого дела дедупликации так же должно повысить фрагментацию при высвобождении блоков во время постпроцессинга. В общем что там с производительностью будет — непонятно. И что с файловыми томами? Компрессия?

А актив актив полноценный? Т.е. он только на «просто» RAID или на пулы тоже? В старых VNX переключить пул было проблемой.

Какая-то хвалебная ода получилась. И везде софт софт софт.

1. Так и не понял, увеличение производительности получено благодаря аппаратному масштабированию (новые процы, больше ядер) или оптимизацией софта?
2. А владельцы старых VNX получат плюшки нового софта? Если нет, то почему?
3. А старые VNX можно как-то относительно просто обновить до новых? Хотя бы полки с дисками?
4. Размер блока при дедупликации какой?

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

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

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

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

Ок, с плоской Землей разобрались.

И чем по вашему «разделение пользовательских пространств» или их «изоляция» не простейший пример контейнеризации?

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

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

А давайте, мы с вами, если уж на то пошло, придем к единому знаменателю уже в ЛС и резюмируем его здесь? Честно, устал уже.

А какой смысл в ЛС? Я не пытаюсь вас исправить, поздно уже. Да и какой смысл искать компромисс между фактом и вымыслом?

В двумерном мире нет земли. И Земли тоже. Это вполне себе реальные объекты реального мира. Вы можете фантазировать на тему проекции шара на плоскость или тому подобного, но не можете говорить «земля бывает плоской». Потому что 1) вы говорите о грунте (верхний обычно плодородный слой планеты Земля); 2) или планете Земля (третья от Солнца планета). В первом случае, в 2D мире нет слоев. Во втором случае, речь о планете, которая суть — «шар». Категоричность и строгость рассуждений — очень разные вещи. Когда вы подменяете понятия, пытаясь найти аналогию или пошутить, сама ценность мысли испаряется, вы путаете сам себя. Это хороший совет, который сильно облегчит общение с серьезными Заказчиками, особенно с гоской.

Терминальный сервер к контейнерам не имеет никакого отношения. Потому что отсутствует ключевой момент — изоляция. Потоковая доставка приложений (ThinApp, часть XenApp, и т.п.) не является терминальной службой, но иногда входит в состав комплекса доставки приложений (тот же XenApp). Вот она, зачастую, изоляцию обеспечивает.

Дедупликация способствует уплотнению ресурсов и в отрыве от виртуализации. Т.е. преимуществом не является. Про VMware TPS рассказывать не надо, а то я вас расстрою.

:) Я за мир, конечно, и за качество контента в блоге уважаемой компании :)