Почему вложенные уровни RAID 1 + 5 или 1 + 6 почти не слышны? Уровни RAID вложенной Статья Википедии в настоящее время отсутствует их разделы. Я не понимаю, почему они не более распространены, чем RAID 1 + 0, особенно по сравнению с RAID 1 + 0 с тройным зеркалированием.

Очевидно, что время восстановления становится все более проблематичным, поскольку объемы накопителей увеличиваются быстрее, чем их производительность или надежность. Мне сказали, что RAID 1 перестраивается быстрее, и что массив RAID 0 из пар RAID 1 позволяет избежать этой проблемы, но, несомненно, так будет и массив RAID 5 или 6 из пар RAID 1. Я бы по крайней мере ожидал, что они будут обычной альтернативой RAID 1 + 0.

Для 16 из 1 ТБ приводим мои расчеты наивной вероятности обращения к резервному копированию, т.е. с упрощенным предположением, что диски независимы с четной вероятностью:

RAID | storage | cumulative probabilities of resorting to backup /m
 1+0 |     8TB | 0, 67, 200, 385, 590, 776, 910, 980, 1000, 1000, 1000
 1+5 |     7TB | 0,  0,   0,  15,  77, 217, 441, 702,  910, 1000, 1000
 1+6 |     6TB | 0,  0,   0,   0,   0,   7,  49, 179,  441,  776, 1000
(m = 0.001, i.e. milli.)

Если это правильно, то совершенно очевидно, что RAID 1 + 6 исключительно надежнее RAID 1 + 0, и емкость хранилища снижена только на 25%. Как и в общем случае, теоретическая пропускная способность записи (не считая времени поиска) представляет собой емкость хранилища / размер массива × количество дисков × пропускную способность записи самого медленного диска в массиве (уровни RAID с избыточностью имеют более высокое усиление записи для операций записи, которые не заполняйте полосу, но это зависит от размера куска), и теоретическая пропускная способность чтения является суммой пропускных способностей чтения дисков в массиве (за исключением того, что RAID 0, RAID 5 и RAID 6 все еще могут быть теоретически ограничены самый медленный, 2-й самый медленный и 3-й самый медленный пропускные способности чтения диска соответственно). Т.е. при условии одинаковых дисков это будет соответственно 8х, 7х,

Кроме того, рассмотрим RAID 0 в четыре раза по сравнению с RAID 1, то есть RAID 1 + 0 с тройным зеркалированием 12 дисков, и RAID 6 с двумя парами RAID 1, т.е. RAID 1 + 6 из 12 дисков. Опять же, это идентичные диски емкостью 1 ТБ. Оба макета имеют одинаковое количество дисков (12), одинаковый объем памяти (4 ТБ), одинаковую долю избыточности (2/3), одинаковую максимальную пропускную способность записи (4 ×) и одинаковую максимальную пропускную способность чтения ( 12 ×). Вот мои расчеты (пока):

RAID      | cumulative probabilities of resorting to backup /m
1+0 (4×3) | 0, 0, 18,  ?,   ?,   ?,   ?,   ?, 1000
1+6 (6×2) | 0, 0,  0,  0,   0,  22, 152, 515, 1000

Да, это может выглядеть излишним, но если для разделения клона для резервного копирования используется тройное зеркалирование, RAID 1 + 6 также можно использовать, просто замораживая и удаляя по 1 каждому диску из всех, кроме 2 из RAID 1 пара, и при этом он все же имеет гораздо лучшую надежность при ухудшении, чем ухудшенный массив RAID 1 + 0. Вот мои расчеты для 12 дисков, ухудшенных на 4 таким образом:

RAID      | cumulative probabilities of resorting to backup /m
1+0 (4×3) | (0, 0, 0, 0), 0, 143, 429, 771, 1000
1+6 (6×2) | (0, 0, 0, 0), 0,   0,  71, 414, 1000

Пропускная способность чтения, однако, может быть снижена до 6х за это время для RAID 1 + 6, тогда как RAID 1 + 0 снижается только до 8х. Тем не менее, если диск выйдет из строя, когда массив находится в этом ухудшенном состоянии, массив RAID 1 + 6 будет иметь 50–50 шансов остаться на уровне около 6 × или быть ограниченным в дальнейшем до 5 ×, тогда как массив RAID 1 + 0 будет ограничиваться 4-х узким местом. Пропускная способность записи должна быть практически незатронутой (она может даже увеличиться, если диски, взятые для резервного копирования, были ограничивающими самыми медленными дисками).

На самом деле, оба могут рассматриваться как «тройное зеркалирование», поскольку деградированный массив RAID 1 + 6 способен разделять дополнительную группу RAID 6 из 4 дисков. Другими словами, эту схему RAID 1 + 6 с 12 накопителями можно разделить на 3 ухудшенных (но функциональных) массива RAID 6!

Так это просто, что большинство людей не вдавались в математику в деталях? Будем ли мы видеть больше RAID 1 + 6 в будущем?

Как правило, я бы сказал, что RAID 1 + 0 будет более широко использоваться, чем 1 + 5 или 1 + 6, поскольку RAID 1 + 0 достаточно надежен и обеспечивает незначительно лучшую производительность и более полезное хранилище.

Я думаю, что большинство людей воспримут сбой полной пары RAID 1 в группе RAID 1 + 0 как довольно редкое событие, для которого стоит разорвать резервные копии, и, вероятно, не слишком увлечены получением менее 50% своего физического диск как полезное пространство.

Если вам нужна лучшая надежность, чем у RAID 1 + 0, тогда сделайте это! ..но большинству людей это, вероятно, не нужно.

Практический ответ лежит где-то на пересечении спецификаций аппаратного RAID-контроллера, средних размеров дисков, форм-факторов накопителей и дизайна сервера.

Большинство аппаратных контроллеров RAID ограничены уровнями RAID, которые они поддерживают. Вот варианты RAID для контроллера HP ProLiant Smart Array:

[raid=0|1|1adm|1+0|1+0adm|5|50|6|60]

примечание: "adm" - это просто тройное отражение

Поддержка LSI RAID контроллеров: 0, 1, 5, 6, 10, 50, and 60

Таким образом, эти контроллеры могут использовать только RAID 50 и 60 как вложенные уровни. LSI (ранее Dell PERC ) и HP составляют большую часть рынка адаптеров систем хранения для корпоративных серверов. Это главная причина, по которой вы не видите что-то вроде RAID 1 + 6 или RAID 61 в полевых условиях.

Помимо этого, для вложенных уровней RAID после RAID 10 требуется относительно большое количество дисков. Учитывая увеличивающиеся емкости дисков, доступные сегодня (с 3,5-дюймовыми накопителями SAS и SATA ближней линии), в сочетании с тем фактом, что многие серверные корпуса спроектированы с 8x2,5-дюймовыми дисковыми отсеками, возможности для физической конфигурации RAID 1+ практически отсутствуют. 6 или RAID 61.

Области, где вы можете увидеть что-то вроде RAID 1 + 6, будут программными решениями RAID для больших шасси. Linux MD RAID или ZFS определенно способны на это. Но к тому времени сбой диска можно смягчить с помощью горячих или холодных дисков. Надежность RAID не является большой проблемой в наши дни, при условии, что вы избежите токсичных комбинаций уровня RAID и аппаратных комбинаций (например, дисков RAID 5 и 6 ТБ). Кроме того, производительность чтения и записи будет ограничена многоуровневым и кэшируемым уровнями. Средние рабочие нагрузки хранилища обычно выигрывают от одного или другого.

Так что, в конце концов, кажется, что потребности / спроса просто нет.

• У вас уменьшается отдача от надежности. RAID 6 вряд ли приведет к отказу даже на жестких дисках SATA со скоростью 1 к 10 ^ 14 UBER. На дисках FC / SAS ваш UBER равен 1 к 10 ^ 16, и вы также получаете значительно большую производительность.

• Надежность RAID-группы не защищает вас от случайного удаления. (так что вам все равно нужны резервные копии)

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

• Напишите штраф. Каждая входящая запись в ваш RAID 61 будет запускать 12 операций ввода-вывода (наивно сделано). RAID 6 уже болезнен в сценариях «низкого уровня» с точки зрения количества операций ввода-вывода в секунду на случайную запись в ТБ. (и на более высоком уровне ваш показатель отказов в 100 раз лучше)

• это не «снижение на 25% », это дальнейшее снижение на 25%. Ваши 16 ТБ превращаются в 6 ТБ. Таким образом, вы получаете 37,5% полезной памяти. Вам нужно в 3 раза больше дисков на емкость и в 3 раза больше дискового пространства. Вы, вероятно, получите больше надежности, просто создав меньшие наборы RAID6. Я не занимался обработкой чисел, но попробую - например, суммы RAID 6 в наборах 3x 3 + 2 (15 дисков, меньше места на диске, чем у вашего RAID10). Или вместо 3-х сторонних зеркал.

Сказав это - это чаще, чем вы думаете, сделать это для многосайтового DR. Я запускаю реплицированные массивы хранения, где у меня есть RAID5 / 6 / DP RAID группы асинхронно или синхронно с DR-сайтом. (Не делайте синхронизацию, если вы можете избежать этого - это выглядит хорошо, это на самом деле ужасно).

С моими NetApps это метрокластер с некоторыми зеркальными агрегатами. С моими VMAX у нас есть Symmetrix Remote Data Facility (SRDF). И мои 3PAR делают удаленное копирование.

Это дорого, но обеспечивает уровень DR для «центра обработки данных».

Что касается тройных зеркал - я использовал их, но не в качестве прямых мер устойчивости RAID, а скорее в качестве полных клонов как части стратегии резервного копирования. Синхронизируйте третье зеркало, разбейте его, смонтируйте на отдельном сервере и выполните резервное копирование, используя совершенно другую инфраструктуру. И иногда поворачивайте третье зеркало как вариант восстановления.

Суть, которую я пытаюсь подчеркнуть, заключается в том, что, исходя из моего непосредственного опыта администратора хранилища - в ~ 40 000 хранилищ шпинделя (да, мы заменяем десятки дисков в день) - нам приходилось делать резервные копии для различных причины за последние 5 лет, но ни одна из них не была сбой группы RAID. Мы обсуждаем относительные достоинства и приемлемое время восстановления, точки восстановления и периоды простоя. И в основе всего этого лежит ВСЕГДА стоимость дополнительной устойчивости.

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

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

Поэтому я думаю, что я бы поэтому предложил ответ на ваш вопрос:

Вы не видите RAID 1 + 6 и 1 + 5 очень часто, потому что экономическая выгода просто не складывается. Учитывая ограниченную сумму денег и необходимость в первую очередь внедрить решение для резервного копирования, все, что вы делаете, - это тратите деньги, чтобы уменьшить частоту отказов. Есть лучшие способы потратить эти деньги.

Современные и продвинутые системы не реализуют такие формы, потому что они чрезмерно сложны, совершенно не нужны и противоречат любой видимости эффективности.

Как уже отмечали другие, отношение необработанного пространства к полезному пространству составляет по существу 3: 1. Это, по сути, три копии (две избыточные копии). Из-за стоимости расчета «raid6» (в два раза больше, если зеркально отражено) и связанной с этим потери IOPS это очень неэффективно. В ZFS, которая очень хорошо спроектирована и настроена, эквивалентным решением с точки зрения емкости будет создание полосы 3-сторонних зеркал.

Например, вместо зеркала с 6-сторонней формой raid6 / raidz2 (всего 12 дисков), что было бы очень неэффективно (к тому же ZFS не имеет какого-либо механизма для реализации), у вас будет 4x 3-сторонних зеркала (также 12 диски). И вместо 1 диска IOPS у вас будет 4 диска IOPS. Особенно с виртуальными машинами, это огромная разница. Общая полоса пропускания для двух форм может быть очень похожа при последовательном чтении / записи, но полоса 3-сторонних зеркал определенно будет более отзывчивой при случайном чтении / записи.

Подводя итог: raid1 + 6 в целом просто непрактичен, неэффективен, и неудивительно, что никто, кто серьезно относится к хранилищу, не подумает о разработке.

Чтобы уточнить несоответствие IOPS: при зеркале форм raid6 / raidz2 при каждой записи все 12 дисков должны действовать как один. Для общей фигуры нет возможности разделить действие на несколько действий, которые несколько фигур могут выполнять независимо. С полосой 3-сторонних зеркал каждая запись может быть чем-то, с чем должен иметь дело только одно из 4-х зеркал, поэтому для другой записи не нужно ждать, пока разберется вся форма омнибуса, прежде чем смотреть на дальнейшие действия. ,

Поскольку никто не сказал об этом достаточно прямо: производительность записи Raid6 ничуть не хуже. Это ужасно за пределами описания, если положить под нагрузкой.

Последовательная запись в порядке, и если кэширование, объединение записей и т. Д. Способно скрыть это, это выглядит нормально. При высокой нагрузке все выглядит плохо, и это главная причина, по которой установка 1 + 5/6 почти никогда не используется.

Искать время

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

RAID | write throughput amplification factor | write seek amplification factor
     | full-stripe (e.g.) | single-chunk     | full-stripe  | single-chunk
   0 | 1           ;  1   | 1           ;  1 | n       ; 12 | 1           ;  1
   1 | n           ; 12   | n           ; 12 | n       ; 12 | n           ; 12
   5 | n/(n - 1)   ; ~1.1 | min [3, n]  ;  3 | n       ; 12 | min [3, n]  ;  3
   6 | n/(n - 2)   ;  1.2 | min [5, n]  ;  5 | n       ; 12 | min [5, n]  ;  5
*1+0 | n₁          ;  3   | n₁          ;  3 | n       ; 12 | n₁          ;  3*
 1+5 | n/(n₅ - 1)  ;  2.4 | expr₁       ;  5 | n       ; 12 | expr₁       ;  5
*1+6 | n/(n₆ - 2)  ;  3   | expr₂       ;  8 | n       ; 12 | expr₂       ;  8*
expr₁ = 2n₁ + min [1, n₅ - 2]
expr₂ = 3n₁ + min [2, n₆ - 3]

где n - общее количество дисков, n₁ - количество дисков в группах RAID 1, а n₅ и n₆ - количество групп в массивах RAID 5 или RAID 6 соответственно. Примеры относятся к 12-приводному примеру в вопросе (соответствующие строки - ' *bolded*'); Примерами уровней RAID 1 + 0, 1 + 5, 1 + 6 являются 4 × 3, 6 × 2, 6 × 2 соответственно.

Обратите внимание, что только коэффициент усиления пропускной способности записи с полной полосой напрямую связан с долей избыточности. Случаи с одним блоком более сложны для тех, кто имеет паритет. Они возникают из-за того, что для записи одного чанка требуется чтение того, что является самым простым из чанков четности или других чанков данных, перед тем как записать чанки четности вместе с новым чанком данных. (Они не являются непосредственно мультипликативными, потому что вместо этого индуцированные чтения должны быть умножены на соответствующий коэффициент усиления пропускной способности чтения / поиска для RAID 1, оба равны 1; см. Ниже.)

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

RAID | large contiguous write throughput    | concurrent tiny writes throughput
     | full-stripe    | single-chunk        | full-stripe | single-chunk
   0 | n×       ; 12× | n×          ; 12×   | 1×     ; 1× | n×          ; 12×
   1 | 1×       ;  1× | 1×          ;  1×   | 1×     ; 1× | 1×          ;  1×
   5 | (n - 1)× ; 11× | max[n/3, 1]×;  4×   | 1×     ; 1× | max[n/3, 1]×;  4×
   6 | (n - 2)× ; 10× | max[n/5, 1]×;  2.4× | 1×     ; 1× | max[n/5, 1]×;  2.4×
*1+0 | n₀×      ;  4× | n₀×         ;  4×   | 1×     ; 1× | n₀×         ;  4×  *
 1+5 | (n₅ - 1)×;  5× | expr₃×      ;  2.4× | 1×     ; 1× | expr₃×      ;  2.4×
*1+6 | (n₆ - 2)×;  4× | expr₄×      ;  1.5× | 1×     ; 1× | expr₄×      ;  1.5×*
expr₃ = n/(2n₁ + min [1, n₅ - 2]) = max [n/(2n₁ + 1), n/(2n₁ + n₅ - 2)]
expr₄ = n/(3n₁ + min [2, n₆ - 3]) = max [n/(3n₁ + 2), n/(3n₁ + n₆ - 3)]

Примечание. Средние 2 столбца пропускной способности можно игнорировать, учитывая разумный размер фрагмента, который больше, чем записи, для которых время поиска является значительным, но достаточно маленьким, чтобы большие записи были полноформатными. Большой размер чанка 2-го столбца пропускной способности больше похож на составные диски. «Крошечная» запись - это то, где влияние пропускной способности незначительно.

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

RAID | read throughput amplification factor | read seek amplification factor
     | full-stripe      | single-chunk      | full-stripe (e.g.) | single-chunk
   0 | 1                | 1                 | n      to n;    12 | 1
   1 | 1                | 1                 | 1      to n;  1–12 | 1
   5 | 1                | 1                 | n - 1  to n; 11–12 | 1
   6 | 1                | 1                 | n - 2  to n; 10–12 | 1
*1+0 | 1                | 1                 | n₀     to n;  4–12 | 1           *
 1+5 | 1                | 1                 | n₅ - 1 to n;  5–12 | 1
*1+6 | 1                | 1                 | n₆ - 2 to n;  4–12 | 1           *

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

RAID | large contiguous read throughput | concurrent tiny reads throughput
     | full-stripe (e.g.)| single-chunk | full-stripe         | single-chunk
   0 | n×          ; 12× | n×     ; 12× | 1×          ;  1×   | n×     ; 12×
   1 | n×          ; 12× | n×     ; 12× | n×          ; 12×   | n×     ; 12×
   5 | n×          ; 12× | n×     ; 12× | n/(n - 1)×  ; ~1.1× | n×     ; 12×
   6 | n×          ; 12× | n×     ; 12× | n/(n - 2)×  ;  1.2× | n×     ; 12×
*1+0 | n×          ; 12× | n×     ; 12× | n₁×         ;  3×   | n×     ; 12×*
 1+5 | n×          ; 12× | n×     ; 12× | n/(n₅ - 1)× ;  2.4× | n×     ; 12×
*1+6 | n×          ; 12× | n×     ; 12× | n/(n₆ - 2)× ;  3×   | n×     ; 12×*

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

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

В действительности, «коэффициент усиления» намного сложнее, чем формула в вопросе, где рассматривалось только усиление пропускной способности с полной полосой. В частности, производительность записи 6 × 2 RAID 1 + 6 для одновременных записей, которые достаточно малы для привязки к поиску, будет хуже, чем у 4 × 3 RAID 1 + 0. А для крошечных записей, которые все ищут, производительность может составлять примерно треть от производительности 4 × 3 RAID 1 + 0 в лучшем случае (т.е. при идеальной реализации).

После устранения этой проблемы сравнение с 12 приводами не имеет явного победителя:

                                  | 4×3 RAID 1+0 | 6×2 RAID 1+6
   number of identical 1TB drives | 12           | 12
                 storage capacity | 4TB          | 4TB
            redundancy proportion | 2/3          | 2/3
large contiguous write throughput | 4×           | 4×
 large contiguous read throughput | 12×          | 12×
concurrent tiny writes throughput |*4×           | 1.5×
 concurrent tiny reads throughput | 12×          | 12×
safe number of random drive loses | 2            |*5
    12 - 1 large write throughput | 4×           | 4×
     12 - 1 large read throughput | 8×           |*11×
    12 - 1 tiny writes throughput |*4×           | ~1.42×
     12 - 1 tiny reads throughput | 8×           |*~9.33×
  can split-off a copy for backup | yes[1]       | yes[1]
                  2-site failover | yes          | yes
    2-copy large write throughput | 4×           | 4×
     2-copy large read throughput |*8×           | 6×
    2-copy tiny writes throughput |*4×           | ~1.28×
     2-copy tiny reads throughput |*8×           | 6×
   2-copy safe random drive loses | 1            |*2
2-copy - 1 large write throughput | 4×           | 4×
 2-copy - 1 large read throughput | 4×           |*5× or 6×[2]
2-copy - 1 tiny writes throughput |*4×           | ~1.46× or 1.2×[2]
 2-copy - 1 tiny reads throughput | 4×           |*3.6x or 6×[2]
can be divided into 3 full copies | yes          | yes
                  3-site failover | yes          | yes
    1-copy large write throughput | 4×           | 4×
     1-copy large read throughput | 4×           | 4×
    1-copy tiny writes throughput |*4×           | ~0.85×
     1-copy tiny reads throughput |*4×           | 2×
   1-copy safe random drive loses | 0            | 0
                       complexity |*simple       | more complex

Примечание 1: Полная копия хранимых данных - это соответственно четырехкратный RAID 0 или массив RAID 6 с ухудшенной 4/6. Примечание 2: Существует четкая вероятность того, что из-за сбоя диска отключится одна из 4 ухудшенных пар RAID 1 или одна из 2 нормальных пар.

Тем не менее, он увеличил бы производительность чтения массива RAID 6 из 6 дисков вдвое, а крошечная пропускная способность записи должна быть на 25% выше (1,5 / 1,2) из-за того, что необходимые чтения были разделены между парами RAID 1, а RAID 6, очевидно, делает это. имеют подходящие приложения, поэтому в высокой доступности приложений , которые имеют большие пишет или которые более обеспокоены чтения производительность , чем производительность записи, может быть, это ниша для RAID 1 + 6 Afterall. Но это не все…

сложность

Пока это только теоретически (в основном комбинаторика ), на практике сложность будет означать, что реализации RAID 1 + 6 могут иметь недостатки, которые упускают возможности и не достигают теоретических результатов. RAID 6 уже более сложен, и вложение еще более усложняет.

Например, не сразу очевидно, что 6 × 2 RAID 1 + 6 можно абстрагировать как наличие 3 независимых виртуальных головок чтения, способных одновременно считывать 3 смежных больших чтения с пропускной способностью 4 × каждая, как 4 × 3 RAID 1 + 0. Простое вложение 6 пар RAID 1 в массив RAID 6 с использованием программного RAID может быть не таким элегантным; реализация может быть глупой и трэш (я пока не проверял эту гипотезу).

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