<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	>
<channel>
	<title>Комментарии к записи: Про tiering: EMC FAST, FASTcache, NetApp Flash Cache</title>
	<atom:link href="http://blog.aboutnetapp.ru/archives/926/feed" rel="self" type="application/rss+xml" />
	<link>http://blog.aboutnetapp.ru/archives/926</link>
	<description>Системы хранения данных как предмет разговора</description>
	<pubDate>Wed, 07 Apr 2021 12:06:00 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.6</generator>
		<item>
		<title>Автор: romx</title>
		<link>http://blog.aboutnetapp.ru/archives/926#comment-3925</link>
		<dc:creator>romx</dc:creator>
		<pubDate>Fri, 12 Oct 2012 00:37:10 +0000</pubDate>
		<guid isPermaLink="false">http://blog.aboutnetapp.ru/archives/926#comment-3925</guid>
		<description>Люба:

Спасибо, действительно, "эшелонирование" или же "ранжирование" будет, наверное, наилучшим вариантом, но во мне, как в переводчике, все равно все восстает от такого перевода.</description>
		<content:encoded><![CDATA[<p>Люба:</p>
<p>Спасибо, действительно, &#8220;эшелонирование&#8221; или же &#8220;ранжирование&#8221; будет, наверное, наилучшим вариантом, но во мне, как в переводчике, все равно все восстает от такого перевода.</p>
]]></content:encoded>
	</item>
	<item>
		<title>Автор: Люба</title>
		<link>http://blog.aboutnetapp.ru/archives/926#comment-3924</link>
		<dc:creator>Люба</dc:creator>
		<pubDate>Thu, 11 Oct 2012 16:17:54 +0000</pubDate>
		<guid isPermaLink="false">http://blog.aboutnetapp.ru/archives/926#comment-3924</guid>
		<description>"Tiering-ом (увы, русскоязычного термина пока не прижилось, будем использовать такое)"

На форуме NetApp Innovation EMEA - 2012 термин "virtual tiering" на русский переводился как "виртуальное эшелонирование" (видимо, по аналогии с авиацией).</description>
		<content:encoded><![CDATA[<p>&#8220;Tiering-ом (увы, русскоязычного термина пока не прижилось, будем использовать такое)&#8221;</p>
<p>На форуме NetApp Innovation EMEA - 2012 термин &#8220;virtual tiering&#8221; на русский переводился как &#8220;виртуальное эшелонирование&#8221; (видимо, по аналогии с авиацией).</p>
]]></content:encoded>
	</item>
	<item>
		<title>Автор: bbk</title>
		<link>http://blog.aboutnetapp.ru/archives/926#comment-2309</link>
		<dc:creator>bbk</dc:creator>
		<pubDate>Wed, 18 Apr 2012 20:10:25 +0000</pubDate>
		<guid isPermaLink="false">http://blog.aboutnetapp.ru/archives/926#comment-2309</guid>
		<description>2romx
У вас в этом посте очепятка http://blog.aboutnetapp.ru/archives/926#comment-1431
вместо Flash Cache, получился "FlexCache". Блин я сам иногда их путаю, надо ж было их так назвать похоже. По-моему НетАпу стоило отставить название PAM II - оно и более логично (типа кэш второго уровня) и нет пересечений в названии.</description>
		<content:encoded><![CDATA[<p>2romx<br />
У вас в этом посте очепятка <a href="http://blog.aboutnetapp.ru/archives/926#comment-1431" rel="nofollow">http://blog.aboutnetapp.ru/archives/926#comment-1431</a><br />
вместо Flash Cache, получился &#8220;FlexCache&#8221;. Блин я сам иногда их путаю, надо ж было их так назвать похоже. По-моему НетАпу стоило отставить название PAM II - оно и более логично (типа кэш второго уровня) и нет пересечений в названии.</p>
]]></content:encoded>
	</item>
	<item>
		<title>Автор: Andrey</title>
		<link>http://blog.aboutnetapp.ru/archives/926#comment-1436</link>
		<dc:creator>Andrey</dc:creator>
		<pubDate>Sun, 12 Jun 2011 20:11:40 +0000</pubDate>
		<guid isPermaLink="false">http://blog.aboutnetapp.ru/archives/926#comment-1436</guid>
		<description>Грустно, что голова 3 года отработала и нужно ее выкидывать (а так же еще 100 штук). Обьемы растут, iops-ов требуется тоже больше.

Btw насколько будет больше оверхед от раздачи файлов через смонтированный lun на файлсервере по iSCSI vs cifs ? Насколько будет больше busy cpu, iops ?</description>
		<content:encoded><![CDATA[<p>Грустно, что голова 3 года отработала и нужно ее выкидывать (а так же еще 100 штук). Обьемы растут, iops-ов требуется тоже больше.</p>
<p>Btw насколько будет больше оверхед от раздачи файлов через смонтированный lun на файлсервере по iSCSI vs cifs ? Насколько будет больше busy cpu, iops ?</p>
]]></content:encoded>
	</item>
	<item>
		<title>Автор: romx</title>
		<link>http://blog.aboutnetapp.ru/archives/926#comment-1433</link>
		<dc:creator>romx</dc:creator>
		<pubDate>Sat, 11 Jun 2011 14:00:37 +0000</pubDate>
		<guid isPermaLink="false">http://blog.aboutnetapp.ru/archives/926#comment-1433</guid>
		<description>&gt; ?? он не тормозит, он сломался 5 мая совсем

Это в жеже глюки, посмотрю при случае. Но лучше, если уж нужен RSS, то подписаться на этот вот: 
http://blog.aboutnetapp.ru/rss</description>
		<content:encoded><![CDATA[<p>> ?? он не тормозит, он сломался 5 мая совсем</p>
<p>Это в жеже глюки, посмотрю при случае. Но лучше, если уж нужен RSS, то подписаться на этот вот:<br />
<a href="http://blog.aboutnetapp.ru/rss" rel="nofollow">http://blog.aboutnetapp.ru/rss</a></p>
]]></content:encoded>
	</item>
	<item>
		<title>Автор: dmarck</title>
		<link>http://blog.aboutnetapp.ru/archives/926#comment-1432</link>
		<dc:creator>dmarck</dc:creator>
		<pubDate>Sat, 11 Jun 2011 13:52:48 +0000</pubDate>
		<guid isPermaLink="false">http://blog.aboutnetapp.ru/archives/926#comment-1432</guid>
		<description>&#62; &lt;i&gt;Это какой такой RSS тормозит?&lt;/i&gt; 

Наврал, это не RSS, это сторонний транслятор

http://aboutnetapp.livejournal.com/profile?mode=full

?? он не тормозит, он сломался 5 мая совсем.

&#62; &lt;i&gt;то можно FlexCache отключить, или же, если необходимо, есть три разных режима кэширования&lt;/i&gt;

Ага, это уже существенно лучше, спасибо.</description>
		<content:encoded><![CDATA[<p>&gt; <i>Это какой такой RSS тормозит?</i> </p>
<p>Наврал, это не RSS, это сторонний транслятор</p>
<p><a href="http://aboutnetapp.livejournal.com/profile?mode=full" rel="nofollow">http://aboutnetapp.livejournal.com/profile?mode=full</a></p>
<p>?? он не тормозит, он сломался 5 мая совсем.</p>
<p>&gt; <i>то можно FlexCache отключить, или же, если необходимо, есть три разных режима кэширования</i></p>
<p>Ага, это уже существенно лучше, спасибо.</p>
]]></content:encoded>
	</item>
	<item>
		<title>Автор: romx</title>
		<link>http://blog.aboutnetapp.ru/archives/926#comment-1431</link>
		<dc:creator>romx</dc:creator>
		<pubDate>Sat, 11 Jun 2011 13:05:13 +0000</pubDate>
		<guid isPermaLink="false">http://blog.aboutnetapp.ru/archives/926#comment-1431</guid>
		<description>&gt; Жалко, что-то RSS тормозит, приходится раз в пару недль сюда прямиком заходить

Это какой такой RSS тормозит? Я вот сам на себя подписан в Google Reader, так все приходит сразу после публикации.

&gt; Кстати, мне с самого начала было интересно: как FlashCache борется с таким характерным паттерном размывания кэша, как линейное чтение больших объёмов (типа потоковой обработки видео или полного бэкапа LUN)? ??нформации об этом я пока нигде не нашёл, но, может, искал плохо.

На таком паттерне просто не рекомендуется изпользовать Flash Cache, и NetApp вообще.
В принципе, если такая задача есть только на каких-то определенных томах системы, то можно FlexCache (софтверный компонент кэширования на уровне Data ONTAP) отключить, или же, если необходимо, есть три разных режима кэширования: "Только метаданные", "high-priority данные" (по умолчанию) или "все данные" (полное кэширование, включая все данные, в том числе low-priopity. sequental read это как раз low-priority data.
Некоторое описание есть в соответствующем TR, есть по нему даже перевод.</description>
		<content:encoded><![CDATA[<p>> Жалко, что-то RSS тормозит, приходится раз в пару недль сюда прямиком заходить</p>
<p>Это какой такой RSS тормозит? Я вот сам на себя подписан в Google Reader, так все приходит сразу после публикации.</p>
<p>> Кстати, мне с самого начала было интересно: как FlashCache борется с таким характерным паттерном размывания кэша, как линейное чтение больших объёмов (типа потоковой обработки видео или полного бэкапа LUN)? ??нформации об этом я пока нигде не нашёл, но, может, искал плохо.</p>
<p>На таком паттерне просто не рекомендуется изпользовать Flash Cache, и NetApp вообще.<br />
В принципе, если такая задача есть только на каких-то определенных томах системы, то можно FlexCache (софтверный компонент кэширования на уровне Data ONTAP) отключить, или же, если необходимо, есть три разных режима кэширования: &#8220;Только метаданные&#8221;, &#8220;high-priority данные&#8221; (по умолчанию) или &#8220;все данные&#8221; (полное кэширование, включая все данные, в том числе low-priopity. sequental read это как раз low-priority data.<br />
Некоторое описание есть в соответствующем TR, есть по нему даже перевод.</p>
]]></content:encoded>
	</item>
	<item>
		<title>Автор: romx</title>
		<link>http://blog.aboutnetapp.ru/archives/926#comment-1430</link>
		<dc:creator>romx</dc:creator>
		<pubDate>Sat, 11 Jun 2011 12:58:21 +0000</pubDate>
		<guid isPermaLink="false">http://blog.aboutnetapp.ru/archives/926#comment-1430</guid>
		<description>По производительности официальные документы, кроме тестирований  SPEC SFS и SPC-1 не публиковались, но частным образом могу сказать, что 3140 производительнее 3020 вдвое, на почти любом типе нагрузки. 3210 производительнее 3140 примерно процентов на файловой, примерно равен на OLTP, и процентов на 40 быстрее на DSS (large sequental read).
3240 быстрее 3140 всюду и всегда (примерно в 1,7..2,0 раза).

Но это неофициальные данные, и за руку меня (или NetApp) не ловите :)

&gt; Дедупликация больше всего выигрыша даст на vmfs, если VM машинки одного типа ОС.

Не обязательно. Она дает выигрыш в случае идентичных данных, а уж будут это VM, файлы с "нулями" или "единицами", или каким-то чередующимся паттерном - это уже детали.</description>
		<content:encoded><![CDATA[<p>По производительности официальные документы, кроме тестирований  SPEC SFS и SPC-1 не публиковались, но частным образом могу сказать, что 3140 производительнее 3020 вдвое, на почти любом типе нагрузки. 3210 производительнее 3140 примерно процентов на файловой, примерно равен на OLTP, и процентов на 40 быстрее на DSS (large sequental read).<br />
3240 быстрее 3140 всюду и всегда (примерно в 1,7..2,0 раза).</p>
<p>Но это неофициальные данные, и за руку меня (или NetApp) не ловите :)</p>
<p>> Дедупликация больше всего выигрыша даст на vmfs, если VM машинки одного типа ОС.</p>
<p>Не обязательно. Она дает выигрыш в случае идентичных данных, а уж будут это VM, файлы с &#8220;нулями&#8221; или &#8220;единицами&#8221;, или каким-то чередующимся паттерном - это уже детали.</p>
]]></content:encoded>
	</item>
	<item>
		<title>Автор: dmarck</title>
		<link>http://blog.aboutnetapp.ru/archives/926#comment-1429</link>
		<dc:creator>dmarck</dc:creator>
		<pubDate>Sat, 11 Jun 2011 12:53:33 +0000</pubDate>
		<guid isPermaLink="false">http://blog.aboutnetapp.ru/archives/926#comment-1429</guid>
		<description>[sidenote] Жалко, что-то RSS тормозит, приходится раз в пару недль сюда прямиком заходить[/sidenote]

Кстати, мне с самого начала было интересно: как FlashCache борется с таким характерным паттерном размывания кэша, как линейное чтение больших объёмов (типа потоковой обработки видео или полного бэкапа LUN)? ??нформации об этом я пока нигде не нашёл, но, может, искал плохо.</description>
		<content:encoded><![CDATA[<p>[sidenote] Жалко, что-то RSS тормозит, приходится раз в пару недль сюда прямиком заходить[/sidenote]</p>
<p>Кстати, мне с самого начала было интересно: как FlashCache борется с таким характерным паттерном размывания кэша, как линейное чтение больших объёмов (типа потоковой обработки видео или полного бэкапа LUN)? ??нформации об этом я пока нигде не нашёл, но, может, искал плохо.</p>
]]></content:encoded>
	</item>
	<item>
		<title>Автор: romx</title>
		<link>http://blog.aboutnetapp.ru/archives/926#comment-1428</link>
		<dc:creator>romx</dc:creator>
		<pubDate>Sat, 11 Jun 2011 12:29:32 +0000</pubDate>
		<guid isPermaLink="false">http://blog.aboutnetapp.ru/archives/926#comment-1428</guid>
		<description>&gt; У нас уже старая голова (FAS3020). ??нтересно сравнение ее с новыми системами, насколько они более производительные, какие benefits получим.

В первую очередь, конечно, поддерживаемость железа, FAS3020, насколько я помню, уже EOL.

Производительность, конечно же. Data ONTAP 8.x, карты расширения PCIe.

&gt; ??нтересует сравнение 2020 vs 3120 vs 32×0, etc
&gt; Куда имеет смысл двигаться ?

С 2020 смысла сравнивать нет, во первых это, с точки зрения дальнейшего развития, тупиковая система. Если стоит задача получить просто новую, поддерживаемую систему из старой 3020, то по производительности ее ближайший аналог, пожалуй, FAS2040.
Однако если есть планы по дальнейшему росту, то надо ориентироваться на 32хх, безусловно.

&gt; ?? есть ли программы апгрейда, когда старая голова идет в зачет.

В Америке - да, есть такое. В России это связано с реэкспортом, что, как вы понимаете, создает такое немыслимое количество гемороя, что заниматься этим никто не будет.
Уж не говоря, что EOL-система уже не нужна никому, она на eBay стоит тыщи три долларов сейчас.

&gt; Технические детали перехода, конечно, тоже важны. Если придется пересоздавать агрегаты - то это жжжж.

aggregates придется пересоздавать (до появления "конвертера") при переходе на 8.х c 64-bit aggregates. При оставлении в рамках линейки 7.x или при использовании 8.x c 32-bit aggregates пересоздавать аггрегейты не нужно.



&gt; Обязательный email в форме не есть хорошо. Может я не хочу его сообщать.
&gt; Выглядит как сбор мейлов 

Ну в каждом доме свои правила. В моем - вот такие. Если вы не согласны - можете не писать сюда, всех и делов. Ваш email нигде не публикуется, разве только вы так изящно, между делом назвали меня спаммером.
Я уже объяснил вам, что комментарии с такими "емэйлами" немедленно валятся в спам, откуда их приходится восстанавливать руками, если успею обнаружить до автоочистки. Меня это утомило, и больше я их спасать оттуда не буду.</description>
		<content:encoded><![CDATA[<p>> У нас уже старая голова (FAS3020). ??нтересно сравнение ее с новыми системами, насколько они более производительные, какие benefits получим.</p>
<p>В первую очередь, конечно, поддерживаемость железа, FAS3020, насколько я помню, уже EOL.</p>
<p>Производительность, конечно же. Data ONTAP 8.x, карты расширения PCIe.</p>
<p>> ??нтересует сравнение 2020 vs 3120 vs 32×0, etc<br />
> Куда имеет смысл двигаться ?</p>
<p>С 2020 смысла сравнивать нет, во первых это, с точки зрения дальнейшего развития, тупиковая система. Если стоит задача получить просто новую, поддерживаемую систему из старой 3020, то по производительности ее ближайший аналог, пожалуй, FAS2040.<br />
Однако если есть планы по дальнейшему росту, то надо ориентироваться на 32хх, безусловно.</p>
<p>> ?? есть ли программы апгрейда, когда старая голова идет в зачет.</p>
<p>В Америке - да, есть такое. В России это связано с реэкспортом, что, как вы понимаете, создает такое немыслимое количество гемороя, что заниматься этим никто не будет.<br />
Уж не говоря, что EOL-система уже не нужна никому, она на eBay стоит тыщи три долларов сейчас.</p>
<p>> Технические детали перехода, конечно, тоже важны. Если придется пересоздавать агрегаты - то это жжжж.</p>
<p>aggregates придется пересоздавать (до появления &#8220;конвертера&#8221;) при переходе на 8.х c 64-bit aggregates. При оставлении в рамках линейки 7.x или при использовании 8.x c 32-bit aggregates пересоздавать аггрегейты не нужно.</p>
<p>> Обязательный email в форме не есть хорошо. Может я не хочу его сообщать.<br />
> Выглядит как сбор мейлов </p>
<p>Ну в каждом доме свои правила. В моем - вот такие. Если вы не согласны - можете не писать сюда, всех и делов. Ваш email нигде не публикуется, разве только вы так изящно, между делом назвали меня спаммером.<br />
Я уже объяснил вам, что комментарии с такими &#8220;емэйлами&#8221; немедленно валятся в спам, откуда их приходится восстанавливать руками, если успею обнаружить до автоочистки. Меня это утомило, и больше я их спасать оттуда не буду.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
