Контейнеры (комьютерное)

[Roman N]

Контейнеры, везде контейнеры. Из серии CoreOS и подобных.
Выглядит заманчиво, сервисы zero-downtime restarts, autodiscovery,
incremental changes, быстрый старт, min distros по 20MB(!) и прочие
прелести.

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

Кто-нибудь готовится использовать в масштабных проектах? Как оно, хорошо
идет?

--Роман

[Ilya L]

Мы используем в контексте вышеупомянутого, т.е. в качестве замены RPM.

Но там более интересные вещи происходят в районе Mesos/Maraphon/Kubernetes.

And the last but not least, a shameless plug ;-)
https://www.youtube.com/watch?v=q0Xg7mVOO8o

--
ilya

[Roman N]

Ilya L wrote on 04-08-15 21:50:

> On 8/4/15 5:53 PM, Roman N wrote:
>> Контейнеры, везде контейнеры. Из серии CoreOS и подобных.
>> Выглядит заманчиво, сервисы zero-downtime restarts, autodiscovery,
>> incremental changes, быстрый старт, min distros по 20MB(!) и прочие
>> прелести.
>>
>> Каждый сервис менеджится и регистрируется локально, никаких dns
>> failover, кластерных файловых систем и прочего корпоративного ужоса.
>>
>> Кто-нибудь готовится использовать в масштабных проектах? Как оно, хорошо
>> идет?
>
> Мы используем в контексте вышеупомянутого, т.е. в качестве замены RPM.
>
> Но там более интересные вещи происходят в районе
> Mesos/Maraphon/Kubernetes.

А я ковыряю более приземленные решения, типа хашикорповского consul.io
или rancher.com

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

От конфигурирования серверов и VM они слегка отошли, должы ощущить вкус.

> And the last but not least, a shameless plug ;-)
> https://www.youtube.com/watch?v=q0Xg7mVOO8o

Ну это, мягко говоря, a lame plug :)

[Ilya L]

On 8/4/15 7:17 PM, Roman N wrote:

>> Но там более интересные вещи происходят в районе
>> Mesos/Maraphon/Kubernetes.
>
> А я ковыряю более приземленные решения, типа хашикорповского consul.io
> или rancher.com
>

consul я не видел. Вроде как типа zookeper-а, только распределенный по
нескольким дейтацентрам. Интересно.

> Все это выглядит как "следующий этап". Я думаю корпорации уже готовы
> платить любые баппки, лишь бы избавится от ручного конфигурирования и
> deployment-а всех этих тупых аппликух. Там такие деньги закопаны сейчас
> что просто ой.
>
> От конфигурирования серверов и VM они слегка отошли, должы ощущить вкус.
>
>> And the last but not least, a shameless plug ;-)
>> https://www.youtube.com/watch?v=q0Xg7mVOO8o
>
> Ну это, мягко говоря, a lame plug :)
>

Bonneville ~= rancher, где каждый контейнер сидит внутри отдельной VM.
VM создается/клонируется VMfork-ом, очень быстро и с маленьким
оверхедом. При этом между контейнерами/VM-ми сохраняется performance and
security isolation. И работает обычная docker infrastructure, including
docker CLI ;-)

Оверхед, все равно, конечно, больше, чем у обычного namespace-based
контейнера. Но бонневильные девелоперы считают, что бенефиты
перевешивают недостатки.

--
ilya

[Roman N]

Ilya L wrote on 05-08-15 4:18:

И главный бенефит - vmware stays in business :)

Тяжело им будет доказать пользу. Народу очень хочется менеджить свои
аппликушки в виде сервисов.

Администрирование vmware, не говря уже об установке железа - это же
невероятный overhead по нынешним меркам. Я бы даже сказал что
администрирование хостов и прочей инфраструктуры в клаудах становится
довольно таки ощутимой luxury.

[Ilya L]

On 8/5/15 9:33 PM, Roman N wrote:

>> Bonneville ~= rancher, где каждый контейнер сидит внутри отдельной
>> VM.
>

> И главный бенефит - vmware stays in business :)
>

Come on, VMware will stay in business one way or another. Где-то эти
контейнеры должны хоститься. On premises или off premises, все равно
оно в VM.

> Тяжело им будет доказать пользу. Народу очень хочется менеджить свои
> аппликушки в виде сервисов.
>
> Администрирование vmware, не говря уже об установке железа - это же
> невероятный overhead по нынешним меркам.

http://vcloud.vmware.com

> Я бы даже сказал что
> администрирование хостов и прочей инфраструктуры в клаудах становится
> довольно таки ощутимой luxury.

Depends. Я знаком с экономикой вопроса со стороны провайдера.
Для больших кастомеров AWS is kind of expensive. Оно хорошо только пока
opex is not a concern.

Плюс у многих regulatory issues.

--
ilya

[somnambulic]

kvm?

[Ilya L]

On 8/5/15 10:11 PM, somnambulic wrote:

> kvm?

kvm это hypervisor. Их дофига разных, хотя ESX, конечно, лучше всех.

Альтернатива VMware это либо OpenStack либо proprietary stack, ala AWS,
а не kvm.

Hypervisor бежит на хосте, хост является частью кластера, кластер
частью pod-а, pod частью datacenter. И это все чем-то должно
управляться. И только поверх лежат контейнеры. У которых свой management
stack, частью которого обычно является docker.

Были попытки делать контейнеры без VM, но оно прижилось только для
специализированных use-cases.

--
ilya

[somnambulic]

On 8/5/15 10:25 PM, Ilya L wrote:
> On 8/5/15 10:11 PM, somnambulic wrote:
>
>> kvm?
>
> kvm это hypervisor. Их дофига разных, хотя ESX, конечно, лучше всех.

а че надо?

>
> Альтернатива VMware это либо OpenStack либо proprietary stack, ala
> AWS, а не kvm.

AWS это сервис а не продукт.

[Ilya L]

On 8/5/15 10:42 PM, somnambulic wrote:

>>> kvm?
>>
>> kvm это hypervisor. Их дофига разных, хотя ESX, конечно, лучше всех.
>
> а че надо?
>
>>
>> Альтернатива VMware это либо OpenStack либо proprietary stack, ala
>> AWS, а не kvm.
>
> AWS это сервис а не продукт.
>

Кто сдает продукт вторичный, тот питается отлично.

Обсуждался management stack, а не продукт. У AWS/EC2 он proprietary stack.

>> Hypervisor бежит на хосте, хост является частью кластера, кластер
>> частью pod-а, pod частью datacenter. И это все чем-то должно
>> управляться. И только поверх лежат контейнеры. У которых свой management
>> stack, частью которого обычно является docker.
>>
>> Были попытки делать контейнеры без VM, но оно прижилось только для
>> специализированных use-cases.
>>
>

--
ilya

[Const]

Мля, какие же вы все тут умные.

А хотите я вам расскажу про опыт реальной, кгхм, виртуализации.
И, кгхм, клаудинга.

А пох, всё равно расскажу.

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

Ну, думаю, чем черт не шутит, дай посмотрю, что ли.
Посмотрел.

Если кто-то думал, что это типа "storage and cpu are allocated
dynamically as needed" - это глубокая ошибка.
На самом деле, когда ты запрашиваешь, э, как бы это выразиться,
cloud resource, его рассматривают три недели.
Потом, э, тебе выделяют, э, одну или сколько там виртуальных машин,
каждая из которых не может иметь более чем 256G мозга и более чем 1Т диска,
и которую (которые) ты должен каждую конфигурировать вручную.
Ну, то есть, как вручную, вручную-то это нормально, это по 10 минут
на машину, но ее конфигурирует-то IT, что означает по 2-8 дней на
отклик на запрос, а запросов в процессе конфигурирования возникает
где-то так 10.

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

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

После реального столкновения я понимаю всё это как
грандиозное наебалово.
Никаких, абсолютно никаких признаков ни виртуального,
ни облачного, там нет и не предполагается.
Тебе просто выделяется машина, одна, индивидуальная
(и так N раз), которую ты сам "конфигуришь", машина совершенно
убогая, меньше, чем десктоп, который я бы сейчас лично себе
домой купил.
Если твои запросы широки как у партизана Боснюка, то ты таких
уебищ можешь заказать прямо сто.
Только непонятно, науя сто таких уебищ могут быть нужны,
когда даже одно такое уебище совершенно нах никому не нужно.

Да, пардон, чуть не забыл про динамическое выделение.
Оно тоже есть и тоже работает как штык.
Просто когда тебе нужно расширить ресурс, ты тоже пишешь
заявку и через какие-нибудь те же три недели it-шные
сисадмины тебе динамически его выделяют.
И ты его динамически, с помощью тех же кривицко-уебков
из it, конфигурируешь, еще несколько недель,
но зато совершенно динамически.

Но всё это, несомненно, виртуально.
То есть, мы видим невъе выгоды и убыстрения от виртуализации.
Просто невероятные.
Раньше, чтобы дать мне тачку с 2T мозга и десятком человеческих FS
занимало неделю, а теперь я не могу получить ее вообще, только
в порядке исключения и за год.
Зато я могу получить виртуальную машину, на которой и солитер
современный не побежит, всего за три недели.

---
Const

[Ilya L]

On 8/5/15 11:30 PM, Const wrote:

> Если кто-то думал, что это типа "storage and cpu are allocated
> dynamically as needed" - это глубокая ошибка.
> На самом деле, когда ты запрашиваешь, э, как бы это выразиться,
> cloud resource, его рассматривают три недели.

Это не Synaptic? Если да, то я very, very, very sorry.

> Потом, э, тебе выделяют, э, одну или сколько там виртуальных машин,
> каждая из которых не может иметь более чем 256G мозга и более чем 1Т диска,
> и которую (которые) ты должен каждую конфигурировать вручную.
> Ну, то есть, как вручную, вручную-то это нормально, это по 10 минут
> на машину, но ее конфигурирует-то IT, что означает по 2-8 дней на
> отклик на запрос, а запросов в процессе конфигурирования возникает
> где-то так 10.

В EC2 d2.8xlarge instance имеет 36 vCores, 244 GB RAM, 48 TB SSD
storage. Создается мгновенно через UI/CLI/API и дает тебе ssh.

https://aws.amazon.com/blogs/aws/next-generation-of-dense-storage-instances-for-ec2/

> То есть, я начал своё путешествие с честной целью.
> Посмотреть, а можно ли мне тоже поучаствовать в этом празднике.
> Предмет прост, текущее приложение бежит на одной линух машине
> с двумя Т мозга и где-то 6 FS, которые есть максимально быстрые
> на рынке доступные диски, сложенные в raid10.
> Разбивается на независимые части пусть не совсем тривиально, но
> без больших страданий.

Значит надо разбить. Лучше много мелких инстансов чем один гигантский.
И от использования FS хорошо бы уйти в сторону S3/hadoop/database.

> Тебе просто выделяется машина, одна, индивидуальная
> (и так N раз), которую ты сам "конфигуришь", машина совершенно
> убогая, меньше, чем десктоп, который я бы сейчас лично себе
> домой купил.

Ужас-ужас.

$ aws ec2 run-instances --image-id ami-xxxxxxxx --count 100500
--instance-type xxxxx --key-name xxxxx --security-groups xxxx

И получите свои 100500 инстанцев, немедленно. С линуксом внутри.

> Если твои запросы широки как у партизана Боснюка, то ты таких
> уебищ можешь заказать прямо сто.
> Только непонятно, науя сто таких уебищ могут быть нужны,
> когда даже одно такое уебище совершенно нах никому не нужно.

Если оно не создается и конфигурируется полностью programmatically
через public API и мгновенно, то это профанация. #cloudwashing

> Да, пардон, чуть не забыл про динамическое выделение.
> Оно тоже есть и тоже работает как штык.
> Просто когда тебе нужно расширить ресурс, ты тоже пишешь
> заявку

В EC2 есть dynamic scaling. Оно само инстансы создает и убивает в
зависимости от load/demand.

http://docs.aws.amazon.com/AutoScaling/latest/DeveloperGuide/as-scale-based-on-demand.html

> и через какие-нибудь те же три недели it-шные
> сисадмины тебе динамически его выделяют.
> И ты его динамически, с помощью тех же кривицко-уебков
> из it, конфигурируешь, еще несколько недель,
> но зато совершенно динамически.
>
> Но всё это, несомненно, виртуально.
> То есть, мы видим невъе выгоды и убыстрения от виртуализации.
> Просто невероятные.
> Раньше, чтобы дать мне тачку с 2T мозга и десятком человеческих FS
> занимало неделю, а теперь я не могу получить ее вообще, только
> в порядке исключения и за год.
> Зато я могу получить виртуальную машину, на которой и солитер
> современный не побежит, всего за три недели.

Не, это не клауд. Это виртуальный datacenter с тщательно заботящимися о
job security IT people.

--
ilya

[Const]

Ilya L <n...@interested.com> wrote:
> В EC2 d2.8xlarge instance имеет 36 vCores, 244 GB RAM, 48 TB SSD
> storage. Создается мгновенно через UI/CLI/API и дает тебе ssh.

> https://aws.amazon.com/blogs/aws/next-generation-of-dense-storage-instances-for-ec2/

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

> Не, это не клауд. Это виртуальный datacenter с тщательно заботящимися о
> job security IT people.

Я сам, б, знаю, что это, б, не клауд, а издевательство.

Вот не знаю, куда настучать, чтобы тех, кто издевается,
за яйца подвесили.

---
Const

[Ilya L]

On 8/6/15 1:05 AM, Const wrote:
> Ilya L <n...@interested.com> wrote:
>> В EC2 d2.8xlarge instance имеет 36 vCores, 244 GB RAM, 48 TB SSD
>> storage. Создается мгновенно через UI/CLI/API и дает тебе ssh.
>
>> https://aws.amazon.com/blogs/aws/next-generation-of-dense-storage-instances-for-ec2/
>
> Ты мне не рассказывай, как это должно быть.
> Я и сам, слава те яйца, еще знаю, как оно должно быть.
> Я тебе рассказываю, как это выглядит в реальной жизни.

AWS доминирует at a rate of $2B per quarter with 80% year-over-year
growth. Coincidentally, в SF невозможно плюнуть и не попадать в
использующий AWS стартап.

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

> Вот не знаю, куда настучать, чтобы тех, кто издевается,
> за яйца подвесили.

Мы виноваты, скорее всего.

--
ilya

[Const]

Ilya L <n...@interested.com> wrote:
> Реальная жизнь пролетает мимо, радостно трубя и сверкая лаковыми
> крыльями. Вам не завидно, Балаганов?

На самом деле - нет, ничуть.
Мои цели были удовлетворены, от меня отъе мудаки,
вопрошающие с как бы наивным видом "Как, а вы что, еще не в облаке ?"
У меня теперь есть обоснованный ответ "а засуньте свое облако
себе в задницу".

> > Вот не знаю, куда настучать, чтобы тех, кто издевается,
> > за яйца подвесили.

> Мы виноваты, скорее всего.

That you are.

---
Const

[DvD]

Вот как только "рассматривают" и между тобой и созданной
машиной/сервисом есть ещё живые люди - тут cloud и заканчивается. Это не
оно.

--
Д

[Roman N]

Const wrote on 06-08-15 2:30:

Зачем работать в такой жопе? :)

А если серьезно, что будет с сервисом если та двух террабайтная машина
того-с? Или там контроллер ляжет (хотя наверняка все резервировано -
то-есть очень дорого). Или перезагрузить нужно будет, according to
patching cycle?

То что ты описал - просто идеальный случай для контейнеров. Пользователь
не должен требовать что-то у IT (ака сделайте мне большую "VM", добавьте
loadbalancer и прочие маловыполнимые запросы). Подготовил аппу в нужном
контейнере, потестил, закачал в local repo, дал команду чувакам деплоить
c параметром http_latency < 30ms. Правда аппу прийдется переписать.

Где и как и сколько они будут запускать этих контейнеров - никого уже не
волнует.

[Slawa Olhovchenkov]

Ilya L <n...@interested.com> wrote:

IL> Значит надо разбить. Лучше много мелких инстансов чем один гигантский.
IL> И от использования FS хорошо бы уйти в сторону S3/hadoop/database.

эм. скажи, это ты так шутишь или просто дурак?

--
Slawa Olhovchenkov

[somnambulic]

ни то ни другое. хотя со вторым может я и тороплюсь:-) в vmware
software-defined storage - жопа.

[Slawa Olhovchenkov]

somnambulic <somna...@yahoo.com> wrote:

s> On 8/6/15 6:22 AM, Slawa Olhovchenkov wrote:
>> Ilya L <n...@interested.com> wrote:
>>
>> IL> Значит надо разбить. Лучше много мелких инстансов чем один гигантский.
>> IL> И от использования FS хорошо бы уйти в сторону S3/hadoop/database.
>>
>> эм. скажи, это ты так шутишь или просто дурак?
>>

s> ни то ни другое. хотя со вторым может я и тороплюсь:-) в vmware
s> software-defined storage - жопа.

S3 -- дорого и медленно.
hadoop -- это вообще не про сторадж (а захочешь на нем FS -- заплачешь горючими слезами
про CAD теорему).
database -- весьма специфически и разогнать ее скажем до отдачи 4ГБайт/с -- я думаю
гораздо сложнее чем проделать тоже самое с FS.

--
Slawa Olhovchenkov

[Ilya L]

On 8/6/15 1:41 AM, Const wrote:

>> Реальная жизнь пролетает мимо, радостно трубя и сверкая лаковыми
>> >крыльями. Вам не завидно, Балаганов?

> На самом деле - нет, ничуть.

0 capex, отсутствие IT, scaling on demand, geo distibution. Мечта стартапа.

--
ilya

[Ilya L]

VMware и VMware SDS тут немного сбоку.

Паттерн заключается в том, чтобы уйти от одного толстого инстанса к
куче мелких инстансов. Это подразумевает отсутствие strongly consistent
storage with filesystem or SQL semantics.

Возвращаясь к VMware, что ты назывешь VMware SDS и в чем в нем жопа? У
нас один SDS - vSAN и оно предназначено для хранение дисков виртуальных
машин.

--
ilya

[Ilya L]

On 8/6/15 8:43 AM, Slawa Olhovchenkov wrote:
> somnambulic <somna...@yahoo.com> wrote:
> s> On 8/6/15 6:22 AM, Slawa Olhovchenkov wrote:
>>> Ilya L <n...@interested.com> wrote:
>>>
>>> IL> Значит надо разбить. Лучше много мелких инстансов чем один гигантский.
>>> IL> И от использования FS хорошо бы уйти в сторону S3/hadoop/database.
>>>
>>> эм. скажи, это ты так шутишь или просто дурак?
>>>
>
> s> ни то ни другое. хотя со вторым может я и тороплюсь:-) в vmware
> s> software-defined storage - жопа.
>
> S3 -- дорого и медленно.
> hadoop -- это вообще не про сторадж (а захочешь на нем FS -- заплачешь горючими слезами
> про CAD теорему).

CAD теорема == Give me Consistency and Availability with posix
semantics or give me Death.

--
ilya

[somnambulic]

кто-нибудь его использует? так же видим новости про ево:рейл.

[Slawa Olhovchenkov]

Ilya L <n...@interested.com> wrote:

IL> On 8/6/15 8:43 AM, Slawa Olhovchenkov wrote:
>> somnambulic <somna...@yahoo.com> wrote:
>> s> On 8/6/15 6:22 AM, Slawa Olhovchenkov wrote:
>>>> Ilya L <n...@interested.com> wrote:
>>>>
>>>> IL> Значит надо разбить. Лучше много мелких инстансов чем один гигантский.
>>>> IL> И от использования FS хорошо бы уйти в сторону S3/hadoop/database.
>>>>
>>>> эм. скажи, это ты так шутишь или просто дурак?
>>>>
>>
>> s> ни то ни другое. хотя со вторым может я и тороплюсь:-) в vmware
>> s> software-defined storage - жопа.
>>
>> S3 -- дорого и медленно.
>> hadoop -- это вообще не про сторадж (а захочешь на нем FS -- заплачешь горючими слезами
>> про CAD теорему).

IL> CAD теорема == Give me Consistency and Availability with posix
IL> semantics or give me Death.

ну т.е. ты предлагаешь поебаться и проебать данные

--
Slawa Olhovchenkov

[Const]

А, в этом смысле.
Тоже не обидно.
Неохота, да и могут не взять.
А своих достаточно хороших идей нет.

---
Const

[Const]

Roman N <datai...@gmail.com> wrote:
> А если серьезно, что будет с сервисом если та двух террабайтная машина
> того-с? Или там контроллер ляжет (хотя наверняка все резервировано -
> то-есть очень дорого).

Разумеется, всё зарезервировано.
И нет, не дорого.

Хочешь я тебе расскажу, что ПО-НАСТОЯЩЕМУ дорого ?
Это когда абсолютно идентичную по смыслу и нагрузке задачу
решают по-современному, красиво.
И это решение в результате бежит на трех кластерах
из нескольких десятков машин каждый.
А попереду этого решения сидит балансировщик нагрузки о трех машинах.
И обслуживает это человек стописят.

> Или перезагрузить нужно будет, according to
> patching cycle?

30 секунд занимает swap to standby и патчи освободившуюся
машину как хочешь.

> То что ты описал - просто идеальный случай для контейнеров. Пользователь
> не должен требовать что-то у IT (ака сделайте мне большую "VM", добавьте
> loadbalancer и прочие маловыполнимые запросы). Подготовил аппу в нужном
> контейнере, потестил, закачал в local repo, дал команду чувакам деплоить
> c параметром http_latency < 30ms. Правда аппу прийдется переписать.

---
Const

[999Vulcan]

On 8/6/2015 3:40 PM, Const wrote:
> Ilya L <n...@interested.com> wrote:
>> On 8/6/15 1:41 AM, Const wrote:
>
>>>> Реальная жизнь пролетает мимо, радостно трубя и сверкая лаковыми
>>>>> крыльями. Вам не завидно, Балаганов?
>
>>> На самом деле - нет, ничуть.
>
>> 0 capex, отсутствие IT, scaling on demand, geo distibution. Мечта стартапа.
>
> А, в этом смысле.
> Тоже не обидно.
> Неохота, да и могут не взять.

ты тут что-то не пропарсил, мне кажется, судя по твоему ответу, но в
ответ на ответ: как так не взять? такого крутого спеца - и не взять?

> А своих достаточно хороших идей нет.

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

[Const]

999Vulcan <z...@vulakh.us> wrote:
> On 8/6/2015 3:40 PM, Const wrote:
> > Ilya L <n...@interested.com> wrote:
> >> On 8/6/15 1:41 AM, Const wrote:
> >
> >>>> Реальная жизнь пролетает мимо, радостно трубя и сверкая лаковыми
> >>>>> крыльями. Вам не завидно, Балаганов?
> >
> >>> На самом деле - нет, ничуть.
> >
> >> 0 capex, отсутствие IT, scaling on demand, geo distibution. Мечта стартапа.
> >
> > А, в этом смысле.
> > Тоже не обидно.
> > Неохота, да и могут не взять.

> ты тут что-то не пропарсил, мне кажется, судя по твоему ответу, но в
> ответ на ответ: как так не взять? такого крутого спеца - и не взять?

Написано же "могут".
Так любого могут, это достаточно сложный и субъективный
процесс, местами политический.

Кроме того, я уже не хочу работать так много.

> > А своих достаточно хороших идей нет.

> у тебя что, день бордо с водкой, что так на самокритику потянуло?

В смысле ?
Если бы были хорошие идеи - я бы даже наплевал на общее
нерасположение ко всякого рода труду и начал бы их
реализовывать.

---
Const

[Sergey Babkin]

On 08/05/2015 10:25 PM, Ilya L wrote:

> Были попытки делать контейнеры без VM, но оно прижилось только для
> специализированных use-cases.

Вообще-то весь гугель так работает. Хотя это конечто специализированный
случай.

-СБ

[Sergey Babkin]

On 08/06/2015 09:33 AM, Ilya L wrote:
> On 8/6/15 8:25 AM, somnambulic wrote:
>> On 8/6/15 6:22 AM, Slawa Olhovchenkov wrote:
>>> Ilya L <n...@interested.com> wrote:
>>>
>>> IL> Значит надо разбить. Лучше много мелких инстансов чем один
>>> гигантский.
>>> IL> И от использования FS хорошо бы уйти в сторону S3/hadoop/database.
>>>
>>> эм. скажи, это ты так шутишь или просто дурак?
>>>
>>
>> ни то ни другое. хотя со вторым может я и тороплюсь:-) в vmware
>> software-defined storage - жопа.
>
> VMware и VMware SDS тут немного сбоку.
>
> Паттерн заключается в том, чтобы уйти от одного толстого инстанса к куче
> мелких инстансов. Это подразумевает отсутствие strongly consistent

Это очевидно дебилизм. Для масштабирования толстые инстансы дешевле
всего.

> storage with filesystem or SQL semantics.

Это тоже дебилизм. Проблема обеспечения нормальной семантики в распределенных
системах - это проблема инфраструктуры. Если ваша инфраструктура этого
не делает, то говно это, а не инфраструктура. А вот всякая эта хрень
с "отсутствием strongly consistent" годится только на нижний уровень
инфраструктуры, поверх которогу будет жить используемый уровень.

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

-СБ

[Ilya L]

Только внутрення специализированная часть Гугла. Контейнеры в Google
Compute, естественно, живут в VM.

--
ilya

[Ilya L]

On 8/7/15 12:22 AM, Sergey Babkin wrote:
> On 08/06/2015 09:33 AM, Ilya L wrote:
>> On 8/6/15 8:25 AM, somnambulic wrote:
>>> On 8/6/15 6:22 AM, Slawa Olhovchenkov wrote:
>>>> Ilya L <n...@interested.com> wrote:
>>>>
>>>> IL> Значит надо разбить. Лучше много мелких инстансов чем один
>>>> гигантский.
>>>> IL> И от использования FS хорошо бы уйти в сторону S3/hadoop/database.
>>>>
>>>> эм. скажи, это ты так шутишь или просто дурак?
>>>>
>>>
>>> ни то ни другое. хотя со вторым может я и тороплюсь:-) в vmware
>>> software-defined storage - жопа.
>>
>> VMware и VMware SDS тут немного сбоку.
>>
>> Паттерн заключается в том, чтобы уйти от одного толстого инстанса к куче
>> мелких инстансов. Это подразумевает отсутствие strongly consistent
>
> Это очевидно дебилизм. Для масштабирования толстые инстансы дешевле
> всего.
>

Зависит от понимания слов масштабирование, дешевле и толстый.

Производительность одной ноды можно наращивать до определенного уровня,
но с какого-то момент нужен horizontal scale-out с несколькими
инстансами. Которые в сумме толще, чем каждый в отдельности. В дешевизне
главное отсутствие человеческого фактора и возможность быстро scale up
and down в зависимости от demand.

>> storage with filesystem or SQL semantics.
>
> Это тоже дебилизм. Проблема обеспечения нормальной семантики в
> распределенных
> системах - это проблема инфраструктуры. Если ваша инфраструктура этого
> не делает, то говно это, а не инфраструктура.

Нормальная семантика для распределенных систем это не (обязательно)
posix или SQL. Часто оно только палки в колеса вставляет.

> А вот всякая эта хрень
> с "отсутствием strongly consistent" годится только на нижний уровень
> инфраструктуры, поверх которогу будет жить используемый уровень.
>

В детсадовском IaaS варианте используемый уровень это "VM" или
"контейнер" или "реплика". Внутри VM, естетственно, обычный Linux или
Windows.

Запущенный внутри инстанса сервис в 2015 году better scale beyond 1 VM
and better not go down if one datacenter is out. А то, действительно, не
возьмут в стартап работать.

Инфраструктура, позволяющая девелоперу создавать такие приложения, это
то, что отличает пригодные для использования платформы от "me too can
cloud".

> И, естественно, от локальных файловых систем для временных рабочих файлов
> и кэша данных деваться некуда, они всех побивахом.

memcached кроет временные рабочие файлы как бык офцу для кеша.

--
ilya

[Ilya L]

On 8/6/15 11:06 AM, somnambulic wrote:

>> Возвращаясь к VMware, что ты назывешь VMware SDS и в чем в нем
>> жопа? У нас один SDS - vSAN и оно предназначено для хранение дисков
>> виртуальных машин.
>>
> кто-нибудь его использует?

Ну, как бы да. Сперва было много VDI deployments. У VSAN 6.0 /
all-flash маркет пошире. It takes time.

Если будете на VMworld, могу свести с людьми, которые могут выдать
конкретные customer studies.

> так же видим новости про ево:рейл.

Новости надо смотреть про EVO:RACK, rail is a toy.

--
ilya

[somnambulic]

On 8/7/15, 11:56 AM, Ilya L wrote:
> On 8/6/15 11:06 AM, somnambulic wrote:
>
>>> Возвращаясь к VMware, что ты назывешь VMware SDS и в чем в нем
>>> жопа? У нас один SDS - vSAN и оно предназначено для хранение дисков
>>> виртуальных машин.
>>>
>> кто-нибудь его использует?
>
> Ну, как бы да. Сперва было много VDI deployments. У VSAN 6.0 /
> all-flash маркет пошире. It takes time.
>
> Если будете на VMworld, могу свести с людьми, которые могут выдать
> конкретные customer studies.

studies это для лохов. vsan revenues == what?

[Sergey Babkin]

On 08/07/2015 11:36 AM, Ilya L wrote:
> On 8/7/15 12:22 AM, Sergey Babkin wrote:
>> On 08/06/2015 09:33 AM, Ilya L wrote:
>>> On 8/6/15 8:25 AM, somnambulic wrote:
>>>> On 8/6/15 6:22 AM, Slawa Olhovchenkov wrote:
>>>>> Ilya L <n...@interested.com> wrote:
>>>>>
>>>>> IL> Значит надо разбить. Лучше много мелких инстансов чем один
>>>>> гигантский.
>>>>> IL> И от использования FS хорошо бы уйти в сторону S3/hadoop/database.
>>>>>
>>>>> эм. скажи, это ты так шутишь или просто дурак?
>>>>>
>>>>
>>>> ни то ни другое. хотя со вторым может я и тороплюсь:-) в vmware
>>>> software-defined storage - жопа.
>>>
>>> VMware и VMware SDS тут немного сбоку.
>>>
>>> Паттерн заключается в том, чтобы уйти от одного толстого инстанса к куче
>>> мелких инстансов. Это подразумевает отсутствие strongly consistent
>>
>> Это очевидно дебилизм. Для масштабирования толстые инстансы дешевле
>> всего.
>>
>
> Зависит от понимания слов масштабирование, дешевле и толстый.
>
> Производительность одной ноды можно наращивать до определенного уровня,
> но с какого-то момент нужен horizontal scale-out с несколькими
> инстансами. Которые в сумме толще, чем каждый в отдельности. В дешевизне

И дешевле, чтобы каждый из них был толстый. А не множество убогих.

> главное отсутствие человеческого фактора и возможность быстро scale up
> and down в зависимости от demand.

demand у Окраинца фиксированный.

>>> storage with filesystem or SQL semantics.
>>
>> Это тоже дебилизм. Проблема обеспечения нормальной семантики в
>> распределенных
>> системах - это проблема инфраструктуры. Если ваша инфраструктура этого
>> не делает, то говно это, а не инфраструктура.
>
> Нормальная семантика для распределенных систем это не (обязательно)
> posix или SQL. Часто оно только палки в колеса вставляет.

Всякое NoSQL - в массе своей говнище, на котором из говна и палок лепят
вручную подобие чего-то нормального для каждого отдельного случая.
Лучше взять уже готовое нормальное (которое может жить поверх NoSQL).

>> А вот всякая эта хрень
>> с "отсутствием strongly consistent" годится только на нижний уровень
>> инфраструктуры, поверх которогу будет жить используемый уровень.
>>
>
> В детсадовском IaaS варианте используемый уровень это "VM" или
> "контейнер" или "реплика". Внутри VM, естетственно, обычный Linux или
> Windows.

Ну, если от него ничего полезного не требуется - то да.

>> И, естественно, от локальных файловых систем для временных рабочих файлов
>> и кэша данных деваться некуда, они всех побивахом.
>
> memcached кроет временные рабочие файлы как бык офцу для кеша.

Память-то гораздо меньше диска.

-СБ

[Ilya L]

On 8/7/15 6:03 PM, somnambulic wrote:
>> Если будете на VMworld, могу свести с людьми, которые могут выдать
>> конкретные customer studies.
>
> studies это для лохов. vsan revenues == what?

Совершенно понятно что не могу disclose VSAN revenue, зачем спрашивать?

Meanwhile,
http://www.theregister.co.uk/2015/08/07/nutanix_digs_itself_into_hole_and_refuses_to_drop_the_shovel/


--
ilya

[Const]

Sergey Babkin <sab...@hotmail.com> wrote:
> И дешевле, чтобы каждый из них был толстый. А не множество убогих.

> > главное отсутствие человеческого фактора и возможность быстро scale up
> > and down в зависимости от demand.

> demand у Окраинца фиксированный.

Я не помню, при чём тут я.
Но да, он относительно фиксированный.
Два раза максимум флуктуации в нормальных условиях,
раз в десять в экстремальных.
Но база постоянно растет, где-то 100% в год.

---
Const

[Ilya L]

On 8/7/15 9:15 PM, Sergey Babkin wrote:

>> Производительность одной ноды можно наращивать до определенного уровня,
>> но с какого-то момент нужен horizontal scale-out с несколькими
>> инстансами. Которые в сумме толще, чем каждый в отдельности. В дешевизне
>
> И дешевле, чтобы каждый из них был толстый. А не множество убогих.
>

Железо хорошо когда толстое. Инстансы хорошо когда тонкие. OS и apps
обычно не скейлятся вертикально после определенного уровня из-за IO
bottlenecks, threading complexity. Плюс, для HA лучше потерять мелкий
инстанс, чем толстый.

>> главное отсутствие человеческого фактора и возможность быстро scale up
>> and down в зависимости от demand.
>
> demand у Окраинца фиксированный.
>

От юзкейса зависит, наверное. Но юзкейс я ведь выбираю, а не наоборот.
То, что 2-3 года назад было shrink-wrapped, these days имеет тенденцию
превращаться в сервис с open-ended demand.

>> Нормальная семантика для распределенных систем это не (обязательно)
>> posix или SQL. Часто оно только палки в колеса вставляет.
>
> Всякое NoSQL - в массе своей говнище, на котором из говна и палок лепят
> вручную подобие чего-то нормального для каждого отдельного случая.
> Лучше взять уже готовое нормальное (которое может жить поверх NoSQL).
>

Что у тебя, что Ольховченко (sic?) вместо аргументов какой-то словесный
понос, как правило.

But its all good, в моей практике поносную точку зрения можно by
default считать ошибочной, что даже улучшает эффективность.

>> memcached кроет временные рабочие файлы как бык офцу для кеша.
>
> Память-то гораздо меньше диска.

Тогда redis, он на диск сбрасывает. Но через пару лет будет
доминировать NVM.

--
ilya

[somnambulic]

On 8/7/15 9:40 PM, Ilya L wrote:
> On 8/7/15 6:03 PM, somnambulic wrote:
>>> Если будете на VMworld, могу свести с людьми, которые могут выдать
>>> конкретные customer studies.
>>
>> studies это для лохов. vsan revenues == what?
>
> Совершенно понятно что не могу disclose VSAN revenue, зачем
> спрашивать?

секретные нули?

>
> Meanwhile,
> http://www.theregister.co.uk/2015/08/07/nutanix_digs_itself_into_hole_and_refuses_to_drop_the_shovel/
>
>
>

[Ilya L]

On 8/7/15 10:05 PM, somnambulic wrote:
> On 8/7/15 9:40 PM, Ilya L wrote:
>> On 8/7/15 6:03 PM, somnambulic wrote:
>>>> Если будете на VMworld, могу свести с людьми, которые могут выдать
>>>> конкретные customer studies.
>>>
>>> studies это для лохов. vsan revenues == what?
>>
>> Совершенно понятно что не могу disclose VSAN revenue, зачем
>> спрашивать?
>
> секретные нули?
>

Это обычная практика не рассказывать про revenue у новых проектов. А уж
когда проект напрямую competes с основным бизнесом of the parent company.

В конце 2014 у VSAN года было 1000+ customers. Тогда Nutanix говорил о
1200 customers и $300M annual runrate. Сейчас у нас 2000 customers. Это
все public information.

You are welcome to multiply apples by oranges at your own risk. ;-)

[somnambulic]

On 8/7/15 10:19 PM, Ilya L wrote:
> On 8/7/15 10:05 PM, somnambulic wrote:
>> On 8/7/15 9:40 PM, Ilya L wrote:
>>> On 8/7/15 6:03 PM, somnambulic wrote:
>>>>> Если будете на VMworld, могу свести с людьми, которые могут
>>>>> выдать
>>>>> конкретные customer studies.
>>>>
>>>> studies это для лохов. vsan revenues == what?
>>>
>>> Совершенно понятно что не могу disclose VSAN revenue, зачем
>>> спрашивать?
>>
>> секретные нули?
>>
>
> Это обычная практика не рассказывать про revenue у новых проектов.

да есть такая практика. и какая основная причина для этой практики?

[Sergey Babkin]

On 08/07/2015 10:00 PM, Ilya L wrote:
> On 8/7/15 9:15 PM, Sergey Babkin wrote:
>
>>> Производительность одной ноды можно наращивать до определенного уровня,
>>> но с какого-то момент нужен horizontal scale-out с несколькими
>>> инстансами. Которые в сумме толще, чем каждый в отдельности. В дешевизне
>>
>> И дешевле, чтобы каждый из них был толстый. А не множество убогих.
>>
>
> Железо хорошо когда толстое. Инстансы хорошо когда тонкие. OS и apps
> обычно не скейлятся вертикально после определенного уровня из-за IO
> bottlenecks, threading complexity. Плюс, для HA лучше потерять мелкий
> инстанс, чем толстый.

Есть задачи, которые embarassibgly parallel. Типа того же поиска в интернетах.
Их легко распределять по многим инстансам. И есть задачи, которые требуют
интеграции многих компонентов - их нельзя просто так побить впоперек.

>>> главное отсутствие человеческого фактора и возможность быстро scale up
>>> and down в зависимости от demand.
>>
>> demand у Окраинца фиксированный.
>>
>
> От юзкейса зависит, наверное. Но юзкейс я ведь выбираю, а не наоборот.

Ась?

>>> Нормальная семантика для распределенных систем это не (обязательно)
>>> posix или SQL. Часто оно только палки в колеса вставляет.
>>
>> Всякое NoSQL - в массе своей говнище, на котором из говна и палок лепят
>> вручную подобие чего-то нормального для каждого отдельного случая.
>> Лучше взять уже готовое нормальное (которое может жить поверх NoSQL).
>>
>
> Что у тебя, что Ольховченко (sic?) вместо аргументов какой-то словесный
> понос, как правило.

Я тебе рассказываю как есть. У NoSQL есть своя ниша. Но даже в этой нише
прямо на нем писать сложно. А вне этой ниши - очень-очень сложно, и многие
писатели делают грубые ошибки. Поэтому люди, которые получили много опыта с
NoSQL (тот же гугель), догадались делать поверх него библиотеку, которая
изображает нормальные транзакции. Уже даже несколько библиотек. Но и у тех
систем есть свои ограничения.
Собственно, показательно, что Главная База Данных в гугеле живет ни в каком
не NoSQL, а в обычной SQLной системе и масштабируется методом увеличения
толщины машин. При том, что казалось бы распределенные базы - вот они,
под боком, используй и получай масштабирование. Но не выходит каменный цветок.

> But its all good, в моей практике поносную точку зрения можно by default
> считать ошибочной, что даже улучшает эффективность.

Так поносность - это у тебя. Ты - теоретик, который слышал разные слова.

>>> memcached кроет временные рабочие файлы как бык офцу для кеша.
>>
>> Память-то гораздо меньше диска.
>
> Тогда redis, он на диск сбрасывает.

Ты как всегда не понимаешь, о чем идет речь. Key-Value - это
маленькое подмножество реальных разновидностей данных.

> Но через пару лет будет доминировать NVM.

Это совсем отдельный интересный вопрос, как поменяются архитектуры софта и
харда в результате.

-СБ

[somnambulic]

On 8/7/15 10:00 PM, Ilya L wrote:
> Тогда redis, он на диск сбрасывает. Но через пару лет будет
> доминировать NVM.

это точно, может через англоязычную пару, т.е. не 2, а типа 3-4 года, но
грядет. и чего тогда будет есть теории?

[Ilya L]

On 8/7/15 10:42 PM, somnambulic wrote:

>> Это обычная практика не рассказывать про revenue у новых проектов.
>
> да есть такая практика. и какая основная причина для этой практики?

Потому что новые продукты часто дают не просто задаром, но еще и с all
you can eat buffet for next year впридачу.

Like, duh!

--
ilya

[Const]

Ilya L <n...@interested.com> wrote:
> On 8/7/15 6:03 PM, somnambulic wrote:
> >> Если будете на VMworld, могу свести с людьми, которые могут выдать
> >> конкретные customer studies.
> >
> > studies это для лохов. vsan revenues == what?

> Совершенно понятно что не могу disclose VSAN revenue, зачем спрашивать?

Какой странный вопрос.
Вы, господин, в зиване или где ?

> Meanwhile,
> http://www.theregister.co.uk/2015/08/07/nutanix_digs_itself_into_hole_and_refuses_to_drop_the_shovel/

А, так я вижу, что вы таки знакомы :)

Я предлагаю решить этот вопрос arm-wrestling-ом !

---
Const

[Const]

Ilya L <n...@interested.com> wrote:
> Что у тебя, что Ольховченко (sic?)

Как это по-российски, посреди спора внезапно обозвать оппонента хохлом.

---
Const

[Ilya L]

On 8/7/15 10:42 PM, Sergey Babkin wrote:

> И есть задачи, которые требуют
> интеграции многих компонентов - их нельзя просто так побить впоперек.
>

>> От юзкейса зависит, наверное. Но юзкейс я ведь выбираю, а не наоборот.
>
> Ась?
>

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

>> Что у тебя, что Ольховченко (sic?) вместо аргументов какой-то словесный
>> понос, как правило.
>
> Я тебе рассказываю как есть. У NoSQL есть своя ниша. Но даже в этой нише
> прямо на нем писать сложно. А вне этой ниши - очень-очень сложно, и многие

> писатели делают грубые ошибки.Поэтому люди, которые получили много опыта с

> NoSQL (тот же гугель), догадались делать поверх него библиотеку, которая
> изображает нормальные транзакции. Уже даже несколько библиотек. Но и у тех
> систем есть свои ограничения.
> Собственно, показательно, что Главная База Данных в гугеле живет ни в каком
> не NoSQL, а в обычной SQLной системе и масштабируется методом увеличения
> толщины машин. При том, что казалось бы распределенные базы - вот они,
> под боком, используй и получай масштабирование. Но не выходит каменный
> цветок.
>

F1?

>> But its all good, в моей практике поносную точку зрения можно by default
>> считать ошибочной, что даже улучшает эффективность.
>
> Так поносность - это у тебя. Ты - теоретик, который слышал разные слова.
>

Ну здрасьте.

>>>> memcached кроет временные рабочие файлы как бык офцу для кеша.
>>>
>>> Память-то гораздо меньше диска.
>>
>> Тогда redis, он на диск сбрасывает.
>
> Ты как всегда не понимаешь, о чем идет речь. Key-Value - это
> маленькое подмножество реальных разновидностей данных.
>

Key-value это один из паттернов хранения и доступа к данным. Redis это
k-v (and more), который позволяет сохранять данные на диске в дополнении
у кешированию их в памяти. Которая гораздо меньше диска.

Общая файловая система сосет в ситуации когда горизонтальные инстансы
пытаются использовать ее как общий кеш. Распределенный k-v store,
хранящий данные в памяти и асинхронно сбрасывающий изменения на диск, рулит.

У реляционных баз c ACID-like фичами тоже, безусловно, есть своя
толстая ниша. Но удовлетворяемые ими задачи мне не интересны.

>> Но через пару лет будет доминировать NVM.
>
> Это совсем отдельный интересный вопрос, как поменяются архитектуры софта и
> харда в результате.

Для начала как-то так:
http://files.diablo-technologies.com/wp-content/uploads/2015/05/Diablo-MCS-with-SQL-Server-on-VSAN-WP.pdf

--
ilya

[Ilya L]

On 8/7/15 11:05 PM, Const wrote:
> Ilya L <n...@interested.com> wrote:
>> On 8/7/15 6:03 PM, somnambulic wrote:
>>>> Если будете на VMworld, могу свести с людьми, которые могут выдать
>>>> конкретные customer studies.
>>>
>>> studies это для лохов. vsan revenues == what?
>
>> Совершенно понятно что не могу disclose VSAN revenue, зачем спрашивать?
>
> Какой странный вопрос.
> Вы, господин, в зиване или где ?
>
>> Meanwhile,
>> http://www.theregister.co.uk/2015/08/07/nutanix_digs_itself_into_hole_and_refuses_to_drop_the_shovel/
>
> А, так я вижу, что вы таки знакомы :)
>

Что, он somnambulic в nutanix?! Danger, danger, abort thread!!!

--
ilya

[Slawa Olhovchenkov]

Ilya L <n...@interested.com> wrote:

IL> On 8/7/15 9:15 PM, Sergey Babkin wrote:

>>> Производительность одной ноды можно наращивать до определенного уровня,
>>> но с какого-то момент нужен horizontal scale-out с несколькими
>>> инстансами. Которые в сумме толще, чем каждый в отдельности. В дешевизне
>>
>> И дешевле, чтобы каждый из них был толстый. А не множество убогих.
>>

IL> Железо хорошо когда толстое. Инстансы хорошо когда тонкие. OS и apps
IL> обычно не скейлятся вертикально после определенного уровня из-за IO
IL> bottlenecks, threading complexity. Плюс, для HA лучше потерять мелкий
IL> инстанс, чем толстый.

есть ньюансы.
если инстанс слишком мелкий -- это тоже очень неудобно.

>>> Нормальная семантика для распределенных систем это не (обязательно)
>>> posix или SQL. Часто оно только палки в колеса вставляет.
>>
>> Всякое NoSQL - в массе своей говнище, на котором из говна и палок лепят
>> вручную подобие чего-то нормального для каждого отдельного случая.
>> Лучше взять уже готовое нормальное (которое может жить поверх NoSQL).
>>

IL> Что у тебя, что Ольховченко (sic?) вместо аргументов какой-то словесный
IL> понос, как правило.

от тебя пока что вместо аргументов вообще поток маркетингвых бузвордов.

IL> But its all good, в моей практике поносную точку зрения можно by
IL> default считать ошибочной, что даже улучшает эффективность.

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

>>> memcached кроет временные рабочие файлы как бык офцу для кеша.
>>
>> Память-то гораздо меньше диска.

IL> Тогда redis, он на диск сбрасывает. Но через пару лет будет
IL> доминировать NVM.

скажи, а у тебя опыт-то с редисом есть?
или ты так, буклетиков почитал?
а то я больше читаю как наебавшись с очередным noSQL люди уходят на постгрес.

--
Slawa Olhovchenkov

[Slawa Olhovchenkov]

Sergey Babkin <sab...@hotmail.com> wrote:

>> Но через пару лет будет доминировать NVM.

SB> Это совсем отдельный интересный вопрос, как поменяются архитектуры софта и
SB> харда в результате.

забыл, кстати, свои пять копеек вставить.
на данный момент NVM -- безумно дорогие, требуют под себя целиком PCIe разъем.
очень забавное, кстати, ограничение нынче -- по количеству PCIe lane и PCIe
разъемов. ну и медленный (по современным временам) QPI.
что, нас, в частности, провоцирует на применение двухпроцессорных машин.

--
Slawa Olhovchenkov

[Ilya L]

On 8/8/15 1:20 AM, Slawa Olhovchenkov wrote:

> IL> Тогда redis, он на диск сбрасывает. Но через пару лет будет
> IL> доминировать NVM.
>
> скажи, а у тебя опыт-то с редисом есть?
> или ты так, буклетиков почитал?
> а то я больше читаю как наебавшись с очередным noSQL люди уходят на постгрес.

Опыт испольщования nosql есть только с Кассандрой, memcached и
GemFire. C postgres тоже есть.

Редис до последнего времени был наш, Сальватор только месяц назад как
из VMware/Pivotal ушел. Так что у меня с редисом с другой стороны есть
некоторый опыт. В том числе и в контексте NVM.

--
ilya

[Sergey Babkin]

On 08/07/2015 11:34 PM, Ilya L wrote:
> On 8/7/15 10:42 PM, Sergey Babkin wrote:
>
>> И есть задачи, которые требуют
>> интеграции многих компонентов - их нельзя просто так побить впоперек.
> >
>>> От юзкейса зависит, наверное. Но юзкейс я ведь выбираю, а не наоборот.
>>
>> Ась?
>>
>
> Я выбираю себе задачи, которые легко параллелизируются и доступны
> пользователем как сервис.

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

>>> Что у тебя, что Ольховченко (sic?) вместо аргументов какой-то словесный
>>> понос, как правило.
>>
>> Я тебе рассказываю как есть. У NoSQL есть своя ниша. Но даже в этой нише
>> прямо на нем писать сложно. А вне этой ниши - очень-очень сложно, и
>> многие
>> писатели делают грубые ошибки.Поэтому люди, которые получили много
>> опыта с
>> NoSQL (тот же гугель), догадались делать поверх него библиотеку, которая
>> изображает нормальные транзакции. Уже даже несколько библиотек. Но и у
>> тех
>> систем есть свои ограничения.
>> Собственно, показательно, что Главная База Данных в гугеле живет ни в
>> каком
>> не NoSQL, а в обычной SQLной системе и масштабируется методом увеличения
>> толщины машин. При том, что казалось бы распределенные базы - вот они,
>> под боком, используй и получай масштабирование. Но не выходит каменный
>> цветок.
>>
>
> F1?

Нет. То есть, F1 - это то, что казалось бы под боком. Впрочем, Х/З,
может нынче она улучшилась и на нее все же перенесли.

>>>>> memcached кроет временные рабочие файлы как бык офцу для кеша.
>>>>
>>>> Память-то гораздо меньше диска.
>>>
>>> Тогда redis, он на диск сбрасывает.
>>
>> Ты как всегда не понимаешь, о чем идет речь. Key-Value - это
>> маленькое подмножество реальных разновидностей данных.
>>
>
> Key-value это один из паттернов хранения и доступа к данным. Redis это
> k-v (and more), который позволяет сохранять данные на диске в дополнении
> у кешированию их в памяти. Которая гораздо меньше диска.
>
> Общая файловая система сосет в ситуации когда горизонтальные инстансы
> пытаются использовать ее как общий кеш. Распределенный k-v store,

Ты значит как всегда не понял, о чем речь. Для кэша данных одного инстанса
есть смысл использовать ЛОКАЛЬНЫЕ диски. А общую файловую систему (точнее,
распределенный сервис, изображающий собой файловую систему или базу данных
хоть SQL хоть NoSQL) - для долговременного хранения.

> У реляционных баз c ACID-like фичами тоже, безусловно, есть своя толстая
> ниша. Но удовлетворяемые ими задачи мне не интересны.

Ну вот и выяснили.

>>> Но через пару лет будет доминировать NVM.
>>
>> Это совсем отдельный интересный вопрос, как поменяются архитектуры
>> софта и
>> харда в результате.
>
> Для начала как-то так:
> http://files.diablo-technologies.com/wp-content/uploads/2015/05/Diablo-MCS-with-SQL-Server-on-VSAN-WP.pdf

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

-СБ

[Ilya L]

On 8/8/15 9:05 AM, Sergey Babkin wrote:

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

Я инженер из R&D. В IT компании. Большой процент и у нас и у наших
пользователей.

>> F1?
>
> Нет. То есть, F1 - это то, что казалось бы под боком. Впрочем, Х/З,
> может нынче она улучшилась и на нее все же перенесли.

Аквалангисты - это хорошо.

>>>>>> memcached кроет временные рабочие файлы как бык офцу для кеша.
>

> Ты значит как всегда не понял, о чем речь. Для кэша данных одного инстанса
> есть смысл использовать ЛОКАЛЬНЫЕ диски.

Когда горизонтально заскейленные инстансы сидят за load balancer и
используют stateless протокол, то локальные диски смысла использовать
нет. И это большой процент.

> А общую файловую систему (точнее,
> распределенный сервис, изображающий собой файловую систему или базу данных
> хоть SQL хоть NoSQL) - для долговременного хранения.
>

Ну хоть тут консенсус. Что настораживает, в соотв. с паттерном
говнометания ;-)

>> Для начала как-то так:
>> http://files.diablo-technologies.com/wp-content/uploads/2015/05/Diablo-MCS-with-SQL-Server-on-VSAN-WP.pdf
>>
>
> Нет. Обрати внимание на то, что обещанная интелом новая память плотно
> привязана к процессору. Использовать ее во внешних массивах - глупо, потому что
> потеряется скорость доступа.

Дальше URL не прочитал? :-)

VSAN это shared-nothing cluster из 50 серверов, в каждом из которых
диски/SSD/NVM + CPU/RAM для hypervisors. Предоставляет RAID поверх
репликации для VMs, которые бегут на тех же серверах. Никаких внешних
массивов.

> Собственно, скажем, в гугельной моедли распределенных систем даже никаких
> изменений не надо, чтобы пользоваться NVRAM. Оно просто внезапно начнет
> гораздо быстрее работать.

При ретрофите сущетвующих систем NVM это альтернатива SSD. И разницы
там довольно много. Во первых, NVM быстрее сети и поэтому должна
кешировать на стороне читателя, а не там, где данные лежат. Во вторых, в
NVM не нужно беспокоиться о limited write cycles и трахаться с log-based
data structures (и TRIM! :-) В третьих, есть масса приложений (Redis),
которым вместо файловой системы лучше дать кусок линейно адресуемой памяти.

--
ilya

[Slawa Olhovchenkov]

Ilya L <n...@interested.com> wrote:

>> Собственно, скажем, в гугельной моедли распределенных систем даже никаких
>> изменений не надо, чтобы пользоваться NVRAM. Оно просто внезапно начнет
>> гораздо быстрее работать.

IL> При ретрофите сущетвующих систем NVM это альтернатива SSD. И разницы
IL> там довольно много. Во первых, NVM быстрее сети и поэтому должна
IL> кешировать на стороне читателя, а не там, где данные лежат. Во вторых, в
IL> NVM не нужно беспокоиться о limited write cycles и трахаться с log-based
IL> data structures (и TRIM! :-) В третьих, есть масса приложений (Redis),
IL> которым вместо файловой системы лучше дать кусок линейно адресуемой памяти.

погоди, я не понял, это ты так (NVM) обозвал NVDIMM?
и с учетом того, что NVMe-то еще стоят несуразных денег,
поддрежки NVDIMM в массовых продуктах я еще не видел -- ты обещаешь что все там будут через два года?


--
Slawa Olhovchenkov

[Sergey Babkin]

On 08/08/2015 10:47 AM, Ilya L wrote:
> On 8/8/15 9:05 AM, Sergey Babkin wrote:
>
>>> Я выбираю себе задачи, которые легко параллелизируются и доступны
>>> пользователем как сервис.
>>
>> Ну ты-то продаешь эту хрень, так что понятно что выбираешь. Но в
>> реальности
>> то, что ты выбираешь - небольшой процент от всех задач.
>>
>
> Я инженер из R&D. В IT компании. Большой процент и у нас и у наших
> пользователей.

Просто у вас небольшой процент пользователей.

>>> F1?
>>
>> Нет. То есть, F1 - это то, что казалось бы под боком. Впрочем, Х/З,
>> может нынче она улучшилась и на нее все же перенесли.
>
> Аквалангисты - это хорошо.

Ась?

>>>>>>> memcached кроет временные рабочие файлы как бык офцу для кеша.
> >
>> Ты значит как всегда не понял, о чем речь. Для кэша данных одного
>> инстанса
>> есть смысл использовать ЛОКАЛЬНЫЕ диски.
>
> Когда горизонтально заскейленные инстансы сидят за load balancer и
> используют stateless протокол, то локальные диски смысла использовать
> нет. И это большой процент.

Ты как всегда не понял, что тебе говорят.

>> А общую файловую систему (точнее,
>> распределенный сервис, изображающий собой файловую систему или базу
>> данных
>> хоть SQL хоть NoSQL) - для долговременного хранения.
>>
>
> Ну хоть тут консенсус. Что настораживает, в соотв. с паттерном
> говнометания ;-)
>
>>> Для начала как-то так:
>>> http://files.diablo-technologies.com/wp-content/uploads/2015/05/Diablo-MCS-with-SQL-Server-on-VSAN-WP.pdf
>>>
>>>
>>
>> Нет. Обрати внимание на то, что обещанная интелом новая память плотно
>> привязана к процессору. Использовать ее во внешних массивах - глупо,
>> потому что
>> потеряется скорость доступа.
>
> Дальше URL не прочитал? :-)

Еще картинки поглядел.

> VSAN это shared-nothing cluster из 50 серверов, в каждом из которых
> диски/SSD/NVM + CPU/RAM для hypervisors. Предоставляет RAID поверх
> репликации для VMs, которые бегут на тех же серверах. Никаких внешних
> массивов.

На картинке нарисован внешний массив, куда они все подключены.

>> Собственно, скажем, в гугельной моедли распределенных систем даже никаких
>> изменений не надо, чтобы пользоваться NVRAM. Оно просто внезапно начнет
>> гораздо быстрее работать.
>
> При ретрофите сущетвующих систем NVM это альтернатива SSD. И разницы там

Ну. Только много, дешево и быстро.

> довольно много. Во первых, NVM быстрее сети и поэтому должна кешировать
> на стороне читателя, а не там, где данные лежат. Во вторых, в NVM не

Кто угодно всегда будет кэшировать на стороне читателя.

> нужно беспокоиться о limited write cycles и трахаться с log-based data
> structures (и TRIM! :-)

Это внутренние подробности. Снаружи они неинтересны. Интересно только то,
что писать можно не целыми блоками, а по чуть-чуть. Но в-принципе
во флэш (если он не изображает собой диск, а с прямым интерфейсом) тоже можно
писать не целыми блоками, а пословно, блоками он только стирается.

> В третьих, есть масса приложений (Redis),
> которым вместо файловой системы лучше дать кусок линейно адресуемой памяти.

Так ты значит не в курсе гугельной модели. Она - твоими словами, shared-nothing
cluster. Писать надо один хрен в несколько мест, а не локально.

-СБ

[Roman N]

Sergey Babkin wrote on 08-08-15 12:05:

> On 08/07/2015 11:34 PM, Ilya L wrote:
>> On 8/7/15 10:42 PM, Sergey Babkin wrote:
>>
>>> И есть задачи, которые требуют
>>> интеграции многих компонентов - их нельзя просто так побить впоперек.
>> >
>>>> От юзкейса зависит, наверное. Но юзкейс я ведь выбираю, а не наоборот.
>>>
>>> Ась?
>>
>> Я выбираю себе задачи, которые легко параллелизируются и доступны
>> пользователем как сервис.
>
> Ну ты-то продаешь эту хрень, так что понятно что выбираешь. Но в реальности
> то, что ты выбираешь - небольшой процент от всех задач.
>

А какие задачи нельзя решить методом предоставления пользователю http
restful гитары c четырьмя буквально струнами и книжонки по API методам?
Которе параллелится только в путь.

И они будут просто счастливы, по сравнению с выкатить им стандартное
интерпрайзное немаштабируемое говно© с проприетарным протоколом.

[Sergey Babkin]

Иди выполни join на двух больших таблицах (или self-join на одной).

-СБ

[Roman N]

Sergey Babkin wrote on 08-08-15 17:49:

Счас, только закажу пару серверов с террабайтом памяти.

[Ilya L]

On 8/8/15 12:53 PM, Slawa Olhovchenkov wrote:

> IL> При ретрофите сущетвующих систем NVM это альтернатива SSD. И разницы
> IL> там довольно много. Во первых, NVM быстрее сети и поэтому должна
> IL> кешировать на стороне читателя, а не там, где данные лежат. Во вторых, в
> IL> NVM не нужно беспокоиться о limited write cycles и трахаться с log-based
> IL> data structures (и TRIM! :-) В третьих, есть масса приложений (Redis),
> IL> которым вместо файловой системы лучше дать кусок линейно адресуемой памяти.
>
> погоди, я не понял, это ты так (NVM) обозвал NVDIMM?
> и с учетом того, что NVMe-то еще стоят несуразных денег,
> поддрежки NVDIMM в массовых продуктах я еще не видел

Я уже давал линк на поддержку Diablo MSC в VSAN.

> -- ты обещаешь что все там будут через два года?

Зуб даю.

--
ilya

[Ilya L]

On 8/8/15 12:57 PM, Sergey Babkin wrote:

>> Я инженер из R&D. В IT компании. Большой процент и у нас и у наших
>> пользователей.
>
> Просто у вас небольшой процент пользователей.
>

Gartner says "About 75% of x86 server workloads are virtualized". They
also say that everyone and their mother are moving to the cloud.

Кобол и мейнфреймы останутся и для их обслуживания будет нужен персонал.
Но настоящая жизнь пролетает мимо...

>>> Нет. То есть, F1 - это то, что казалось бы под боком. Впрочем, Х/З,
>>> может нынче она улучшилась и на нее все же перенесли.
>>
>> Аквалангисты - это хорошо.
>
> Ась?
>

Песня группы Манго-Манго. В которой есть строчка "У нас есть такие
приборы. Но мы вам о них не расскажем.".

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

Объясни, чем локальные файлы лучше, чем memcached для кеширования
полученных из Кассандры данных кластером горизонтально заскейленные
инстансов.

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

>>>> Для начала как-то так:
>>>> http://files.diablo-technologies.com/wp-content/uploads/2015/05/Diablo-MCS-with-SQL-Server-on-VSAN-WP.pdf
>

> На картинке нарисован внешний массив, куда они все подключены.
>

Нет там внешнего массива. Есть shared nothing horizontal scaleout как я
описал. Hyper-convergence. You will be hearing this word a lot.

>> довольно много. Во первых, NVM быстрее сети и поэтому должна кешировать
>> на стороне читателя, а не там, где данные лежат. Во вторых, в NVM не
>
> Кто угодно всегда будет кэшировать на стороне читателя.
>

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

>> нужно беспокоиться о limited write cycles и трахаться с log-based data
>> structures (и TRIM! :-)
>
> Это внутренние подробности. Снаружи они неинтересны.

Они интересны тем, кто имплементирует поддержку NVM.

> Так ты значит не в курсе гугельной модели. Она - твоими словами,
> shared-nothing
> cluster. Писать надо один хрен в несколько мест, а не локально.

Я только про F1/Spanner/CockroachDB знаю немного. Рассказывай.

--
ilya

[Ilya L]

On 8/8/15 2:49 PM, Sergey Babkin wrote:

>> И они будут просто счастливы, по сравнению с выкатить им стандартное
>> интерпрайзное немаштабируемое говно© с проприетарным протоколом.
>
> Иди выполни join на двух больших таблицах

Заменить на одну sparse table.

> (или self-join на одной).

map-reduce. Google "similarity join".

--
ilya

[Slawa Olhovchenkov]

Ilya L <n...@interested.com> wrote:

IL> On 8/8/15 12:53 PM, Slawa Olhovchenkov wrote:

>> IL> При ретрофите сущетвующих систем NVM это альтернатива SSD. И разницы
>> IL> там довольно много. Во первых, NVM быстрее сети и поэтому должна
>> IL> кешировать на стороне читателя, а не там, где данные лежат. Во вторых, в
>> IL> NVM не нужно беспокоиться о limited write cycles и трахаться с log-based
>> IL> data structures (и TRIM! :-) В третьих, есть масса приложений (Redis),
>> IL> которым вместо файловой системы лучше дать кусок линейно адресуемой памяти.
>>
>> погоди, я не понял, это ты так (NVM) обозвал NVDIMM?
>> и с учетом того, что NVMe-то еще стоят несуразных денег,
>> поддрежки NVDIMM в массовых продуктах я еще не видел

IL> Я уже давал линк на поддержку Diablo MSC в VSAN.

и что мне этот линк должен был сказать?

>> -- ты обещаешь что все там будут через два года?

IL> Зуб даю.

чей?

--
Slawa Olhovchenkov

[Slawa Olhovchenkov]

Ilya L <n...@interested.com> wrote:

>>> довольно много. Во первых, NVM быстрее сети и поэтому должна кешировать
>>> на стороне читателя, а не там, где данные лежат. Во вторых, в NVM не
>>
>> Кто угодно всегда будет кэшировать на стороне читателя.
>>

IL>
IL> Ну щас. SSD медленнее, чем локальная сеть и поэтому используется для
IL> кеширования на той стороне, где данные лежат на диске.

что-то я не понимаю этих рассуждений. можешь раскрыть?
да, один обычный SSD медленней 10G сетки.
два -- уже сравнимы.
восемь -- около 40Г сетки.
только к чему эти сравнения?
типа по сети спросить быстрее чем с SSD прочитать?
а по сети они откуда возьмутся? еще раз по сети?
или с HDD вычисляться будут? или с тех же SSD?
ну не в памяти же все там храниться будет -- памяти на всех не хватит,
ну или в своей же хранить.

--
Slawa Olhovchenkov

[Dmitry Krivitsky]

On 8/9/2015 7:15 AM, Slawa Olhovchenkov wrote:
> Ilya L <n...@interested.com> wrote:
>
>>>> довольно много. Во первых, NVM быстрее сети и поэтому должна кешировать
>>>> на стороне читателя, а не там, где данные лежат. Во вторых, в NVM не
>>>
>>> Кто угодно всегда будет кэшировать на стороне читателя.
>>>
> IL>
> IL> Ну щас. SSD медленнее, чем локальная сеть и поэтому используется для
> IL> кеширования на той стороне, где данные лежат на диске.
>
> что-то я не понимаю этих рассуждений. можешь раскрыть?
> да, один обычный SSD медленней 10G сетки.

http://www.intel.com/content/www/us/en/solid-state-drives/solid-state-drives-dc-p3700-series.html

Это медленнее сетки?

[Sergey Babkin]

On 08/08/2015 11:11 PM, Ilya L wrote:
> On 8/8/15 12:57 PM, Sergey Babkin wrote:
>
>>> Я инженер из R&D. В IT компании. Большой процент и у нас и у наших
>>> пользователей.
>>
>> Просто у вас небольшой процент пользователей.
>>
>
> Gartner says "About 75% of x86 server workloads are virtualized". They
> also say that everyone and their mother are moving to the cloud.

Следим за руками: то, что у кого-то что-то где-то крутится в VM,
совсем не означает, что они клиенты вашей IT компании, и что у них
срамно параллельные задачи.

>>>> Нет. То есть, F1 - это то, что казалось бы под боком. Впрочем, Х/З,
>>>> может нынче она улучшилась и на нее все же перенесли.
>>>
>>> Аквалангисты - это хорошо.
>>
>> Ась?
>>
>
> Песня группы Манго-Манго. В которой есть строчка "У нас есть такие
> приборы. Но мы вам о них не расскажем.".

Так вот я тебе рассказал.

>>> Когда горизонтально заскейленные инстансы сидят за load balancer и
>>> используют stateless протокол, то локальные диски смысла использовать
>>> нет. И это большой процент.
>>
>> Ты как всегда не понял, что тебе говорят.
>>
>
> Объясни, чем локальные файлы лучше, чем memcached для кеширования
> полученных из Кассандры данных кластером горизонтально заскейленные
> инстансов.

Размером. Ценой. Отсутствием нагрузки на сеть, которая является узким местом.
И нет, жизнь не ограничивается "полученными из Кассандры данными".

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

Пожалуйста.

>>>>> Для начала как-то так:
>>>>> http://files.diablo-technologies.com/wp-content/uploads/2015/05/Diablo-MCS-with-SQL-Server-on-VSAN-WP.pdf
>>>>>
>>
>> На картинке нарисован внешний массив, куда они все подключены.
>>
>
> Нет там внешнего массива. Есть shared nothing horizontal scaleout как я
> описал. Hyper-convergence. You will be hearing this word a lot.
>
>>> довольно много. Во первых, NVM быстрее сети и поэтому должна кешировать
>>> на стороне читателя, а не там, где данные лежат. Во вторых, в NVM не
>>
>> Кто угодно всегда будет кэшировать на стороне читателя.
>>
>
> Ну щас. SSD медленнее, чем локальная сеть и поэтому используется для
> кеширования на той стороне, где данные лежат на диске.

Память, Карл, память!

>> Так ты значит не в курсе гугельной модели. Она - твоими словами,
>> shared-nothing
>> cluster. Писать надо один хрен в несколько мест, а не локально.
>
> Я только про F1/Spanner/CockroachDB знаю немного. Рассказывай.

Ну так ты же должен и сам знать, что этот share-nothing означает.

Слово BigTable слышал? Это тот самый распределенный key-value store. Его можно
использовать напрямую или поверх него есть интерфейсы файловой системы и
реляционной базы (megastore/datastore/f1). И всякие более
многослойные конструкции типа Dremel и просто так честные реляционные СУБД.
Пишут, что spanner - новая версия BigTable, но фиг его знает, возможно
и скорее всего тоже на самом деле сделано как дополнительный слой.

Кстати, специально для тебя в википедии пишут:
The lack of transactions in BigTable led to frequent complaints from users, so
Google made distributed transactions central to the Spanner's design. Based on
its experience with BigTable, Google argues that it is better to have
application programmers deal with performance problems due to overuse of
transactions as bottlenecks arise, rather than always coding around the lack of
transactions.

В megastore/datastore проблема транзакций решалась совершенно монструозным
способом.

Приложение пишется в виде stateless программ и отдельно слоя хранения
данных. Слой хранения данных - географически распределенный, с копиями данных
в разных кластерах (и BigTable дает избыточность с устойчивостью
к потере машин в одном кластере). Ну, кроме интерфейса файловой системы,
она более отсталая. С точки зрения программ хранение выглядит
как сервер(ы) обычно в том же кластере, а про географическую распределенность
они друг с другом разбираются сами внутри себя (плюс сисадмином, поэтому
в гугеле столько сисадминов). Помимо того есть всякие сервисы, начиная с того,
который запускает программы (borg) вместе с name service, который позволяет их
находить, distributed lock manager (очень важная штука, в нее упирается
совершенно все), всякие load balancers и прочая.

-СБ

[Sergey Babkin]

Тут мы видим непонимание того, что такое join, и что такое map-reduce.
К твоему сведению, map-reduce - это агрегация, то есть group-by.

-СБ

[Slawa Olhovchenkov]

Dmitry Krivitsky <kr...@fido.fw.nu> wrote:

DK> On 8/9/2015 7:15 AM, Slawa Olhovchenkov wrote:
>> Ilya L <n...@interested.com> wrote:
>>
>>>>> довольно много. Во первых, NVM быстрее сети и поэтому должна кешировать
>>>>> на стороне читателя, а не там, где данные лежат. Во вторых, в NVM не
>>>>
>>>> Кто угодно всегда будет кэшировать на стороне читателя.
>>>>
>> IL>
>> IL> Ну щас. SSD медленнее, чем локальная сеть и поэтому используется для
>> IL> кеширования на той стороне, где данные лежат на диске.
>>
>> что-то я не понимаю этих рассуждений. можешь раскрыть?
>> да, один обычный SSD медленней 10G сетки.

DK> http://www.intel.com/content/www/us/en/solid-state-drives/solid-state-drives-dc-p3700-series.html

DK> Это медленнее сетки?

это уже называют NVMe. и да, медленней 40G сетки.

--
Slawa Olhovchenkov

[Dmitry Krivitsky]

Что-то ваша с Лангуевым терминология стала для меня совсем загадочной.
NVMe - это ж, вроде, просто интерфейс такой, и от его использования
SSD не становится менее SSD.
Конкретно то, на что я привел линк - чем оно тебе не SSD?

> и да, медленней 40G сетки.

Ты обещал медленнее 10G. :-)

[Slawa Olhovchenkov]

Dmitry Krivitsky <kr...@fido.fw.nu> wrote:

DK> On 8/9/2015 7:40 AM, Slawa Olhovchenkov wrote:
>> Dmitry Krivitsky <kr...@fido.fw.nu> wrote:
>> DK> On 8/9/2015 7:15 AM, Slawa Olhovchenkov wrote:
>>>> Ilya L <n...@interested.com> wrote:
>>>>
>>>>>>> довольно много. Во первых, NVM быстрее сети и поэтому должна кешировать
>>>>>>> на стороне читателя, а не там, где данные лежат. Во вторых, в NVM не
>>>>>>
>>>>>> Кто угодно всегда будет кэшировать на стороне читателя.
>>>>>>
>>>> IL>
>>>> IL> Ну щас. SSD медленнее, чем локальная сеть и поэтому используется для
>>>> IL> кеширования на той стороне, где данные лежат на диске.
>>>>
>>>> что-то я не понимаю этих рассуждений. можешь раскрыть?
>>>> да, один обычный SSD медленней 10G сетки.
>>
>> DK> http://www.intel.com/content/www/us/en/solid-state-drives/solid-state-drives-dc-p3700-series.html
>>
>> DK> Это медленнее сетки?
>>
>> это уже называют NVMe.

DK> Что-то ваша с Лангуевым терминология стала для меня совсем загадочной.

для меня лангувская тоже загадочна.
я так и не понял что он имеет ввиду под NVM.
а сам он -- не признается и только подсовывает комиксы.

DK> NVMe - это ж, вроде, просто интерфейс такой, и от его использования
DK> SSD не становится менее SSD.

NVMe -- это PCIe x4, выведенное по SFF-8639 на собственно то, что хранит.
т.е. собственно предел по интерфейсу -- почти 40Гбит (ну или 5ГБ/с).

DK> Конкретно то, на что я привел линк - чем оно тебе не SSD?

а SSD -- это SATA-3 (6Gbit/s в кодировке 8/10), т.е. предел по интерфейсу -- порядка 600МБ/с.
наверное есть и в SAS-3 (12Gbit/s) -- но не встречал.

>> и да, медленней 40G сетки.

DK> Ты обещал медленнее 10G. :-)

я сказал _обычный SSD_. ты привел -- не обычный, он с другим интерфейсом и в 10 раз дороже.

--
Slawa Olhovchenkov

[Dmitry Krivitsky]

On 8/9/2015 9:02 AM, Slawa Olhovchenkov wrote:
>
> а SSD -- это SATA-3

Нет.
SSD - он и в Африке SSD, независимо от того, с каким он интерфейсом.

> я сказал _обычный SSD_. ты привел -- не обычный, он с другим интерфейсом и в 10 раз дороже.

Я привел серверный, а не десктопный/лаптопный.
Кстати, даже и обычные-то диски в серверах обычно SAS, а не SATA.

[Slawa Olhovchenkov]

Dmitry Krivitsky <kr...@fido.fw.nu> wrote:

DK> On 8/9/2015 9:02 AM, Slawa Olhovchenkov wrote:
>>
>> а SSD -- это SATA-3

DK> Нет.
DK> SSD - он и в Африке SSD, независимо от того, с каким он интерфейсом.

>> я сказал _обычный SSD_. ты привел -- не обычный, он с другим интерфейсом и в 10 раз дороже.

DK> Я привел серверный, а не десктопный/лаптопный.

это специфическая хрень.
Intel Pro 2500, к примеру, позиционируется как серверный, не смотря на SATA.

DK> Кстати, даже и обычные-то диски в серверах обычно SAS, а не SATA.

ну это если только 15к хочешь. в остальных случаях смысла нет.

--
Slawa Olhovchenkov

[Ilya L]

On 8/9/15 3:45 AM, Slawa Olhovchenkov wrote:

>>> поддрежки NVDIMM в массовых продуктах я еще не видел
>
> IL> Я уже давал линк на поддержку Diablo MSC в VSAN.
>
> и что мне этот линк должен был сказать?
>

Что Diablo MSC это NAND flash, который вставляется в DIMM slot и имеет
DDR3 interface. Поддерживается в массовом продуктах ESXi и VSAN.

>>> -- ты обещаешь что все там будут через два года?
> IL> Зуб даю.
>
> чей?
>

Твой?

--
ilya

[Ilya L]

On 8/9/15 4:15 AM, Slawa Olhovchenkov wrote:

> типа по сети спросить быстрее чем с SSD прочитать?
> а по сети они откуда возьмутся? еще раз по сети?
> или с HDD вычисляться будут? или с тех же SSD?

С SSD, используемых в качестве кеша для данных, хранимых на диске. (Или
с быстрых SSD, используемых в качестве кеша для медленных SSD).

То, что медленне сетки (например, SSD, вставленное в SATA), надо
использовать для кеширования на ремотной стороне. То, что быстрее или
сравнимо с сеткой (например RAM, NVM), надо использовать на локальной
стороне.

--
ilya

[Slawa Olhovchenkov]

Ilya L <n...@interested.com> wrote:

IL> On 8/9/15 3:45 AM, Slawa Olhovchenkov wrote:

>>>> поддрежки NVDIMM в массовых продуктах я еще не видел
>>
>> IL> Я уже давал линк на поддержку Diablo MSC в VSAN.
>>
>> и что мне этот линк должен был сказать?
>>

IL> Что Diablo MSC это NAND flash, который вставляется в DIMM slot и имеет

по данному линку эта информация отсутствует.

IL> DDR3 interface. Поддерживается в массовом продуктах ESXi и VSAN.

современные сервера идут с DDR4.
гугл не находит ни одного предложения по продаже Diablo MSC.
на сайте даже даташитов нет.
нахуй так жить?

>>>> -- ты обещаешь что все там будут через два года?
>> IL> Зуб даю.
>>
>> чей?
>>

IL> Твой?

ну щаз.

--
Slawa Olhovchenkov

[Ilya L]

On 8/9/15 4:21 AM, Dmitry Krivitsky wrote:

>> что-то я не понимаю этих рассуждений. можешь раскрыть?
>> да, один обычный SSD медленней 10G сетки.
>
> http://www.intel.com/content/www/us/en/solid-state-drives/solid-state-drives-dc-p3700-series.html
>
> Это медленнее сетки?
>

Естественно, я имел ввиду SATA/SAS SSDs. Хотя PCIe все равно медленне,
чем 40Gbit network.

Чем быстрее storage, тем выгоднее ее держать ближе к консумеру.

--
ilya

[Slawa Olhovchenkov]

Ilya L <n...@interested.com> wrote:

IL> On 8/9/15 4:15 AM, Slawa Olhovchenkov wrote:

>> типа по сети спросить быстрее чем с SSD прочитать?
>> а по сети они откуда возьмутся? еще раз по сети?
>> или с HDD вычисляться будут? или с тех же SSD?

IL> С SSD, используемых в качестве кеша для данных, хранимых на диске. (Или
IL> с быстрых SSD, используемых в качестве кеша для медленных SSD).

IL> То, что медленне сетки (например, SSD, вставленное в SATA), надо
IL> использовать для кеширования на ремотной стороне. То, что быстрее или
IL> сравнимо с сеткой (например RAM, NVM), надо использовать на локальной
IL> стороне.

мне кажется ты даже не задумался над моим возражением

--
Slawa Olhovchenkov

[Ilya L]

On 8/9/15 4:34 AM, Sergey Babkin wrote:

>> Gartner says "About 75% of x86 server workloads are virtualized". They
>> also say that everyone and their mother are moving to the cloud.
>
> Следим за руками: то, что у кого-то что-то где-то крутится в VM,
> совсем не означает, что они клиенты вашей IT компании

Garner says "For a sixth year in a row, we are proud to announce VMware
is once again a leader in the Gartner Magic Quadrant for x86 Server
Virtualization Infrastructure".

> , и что у них срамно параллельные задачи.

Simon didn't say :-)

>> Объясни, чем локальные файлы лучше, чем memcached для кеширования
>> полученных из Кассандры данных кластером горизонтально заскейленные
>> инстансов.
>
> Размером. Ценой. Отсутствием нагрузки на сеть, которая является узким
> местом.

И то, что разные запросы в одной сессии приходят на разные инстансы,
это ничего?

>> Ну щас. SSD медленнее, чем локальная сеть и поэтому используется для
>> кеширования на той стороне, где данные лежат на диске.
>
> Память, Карл, память!
>

Речь шла о том, где лучше использовать SSD и где лучше использовать
"память". Тезис состоит в том, что SSD нужно/можно использовать over the
network, а "память" нужно использовать локально. Что приводит к
необходимости редизайна storage systems при переходе с SSD на NVM.

> Слово BigTable слышал? Это тот самый распределенный key-value store. Его
> можно использовать напрямую или поверх него есть интерфейсы файловой системы и
> реляционной базы (megastore/datastore/f1).

Мне казалось, что BT/GFS не поддерживают репликацию по линкам с высоким
latency. И partitioning не поддерживает. Если поддерживает, но не совсем
понятно, как можно поверх положить layer, дающий ACID семантику.

Мне надо, чтобы можно было читать и писать одни и те же данные в разных
datacenters, расположенных в 100 ms друг от друга. При этом потеря
connectivity между datacenters не должна приводить к отсутствию
возможности читать-писать. Можно это сделать с помощью BT/F1?

> В megastore/datastore проблема транзакций решалась совершенно монструозным
> способом.
>
> Приложение пишется в виде stateless программ и отдельно слоя хранения
> данных. Слой хранения данных - географически распределенный, с копиями
> данных
> в разных кластерах (и BigTable дает избыточность с устойчивостью
> к потере машин в одном кластере).

Это как оно решалось до того, как на BigTable положили что-то более
удобное и транзакционное?


--
ilya

[Ilya L]

On 8/9/15 4:35 AM, Sergey Babkin wrote:

>> > (или self-join на одной).
>>
>> map-reduce. Google "similarity join".
>
> Тут мы видим непонимание того, что такое join, и что такое map-reduce.
> К твоему сведению, map-reduce - это агрегация, то есть group-by.
>

Бабкин, reduce-side join это такой фундаментальный map-reduce pattern.
Self-similarity join это разновидность reduce-side join. Им можно
сделать, например, эквивалент классического employee-manager self-join
из SQL.

--
ilya

[Ilya L]

On 8/9/15 11:39 AM, Slawa Olhovchenkov wrote:

> IL> Что Diablo MSC это NAND flash, который вставляется в DIMM slot и имеет
>
> по данному линку эта информация отсутствует.
>

У вас там гугл импортнозаместили?

http://www.storagereview.com/diablo_s_mcs_architecture_integrated_into_lenovo_x6_servers

> IL> DDR3 interface. Поддерживается в массовом продуктах ESXi и VSAN.
>
> современные сервера идут с DDR4.
> гугл не находит ни одного предложения по продаже Diablo MSC.
> на сайте даже даташитов нет.

В retail оно называется Lenovo eXFlash™ DIMM и SanDisk ULLtraDIMM™.

http://www.diablo-technologies.com/server-vendor/


Щас будут обвинять меня в том, что я продавец Леново...

--
ilya

[Ilya L]

On 8/9/15 11:41 AM, Slawa Olhovchenkov wrote:

>>> типа по сети спросить быстрее чем с SSD прочитать?
>>> а по сети они откуда возьмутся? еще раз по сети?
>>> или с HDD вычисляться будут? или с тех же SSD?
>
> IL> С SSD, используемых в качестве кеша для данных, хранимых на диске. (Или
> IL> с быстрых SSD, используемых в качестве кеша для медленных SSD).
>
> IL> То, что медленне сетки (например, SSD, вставленное в SATA), надо
> IL> использовать для кеширования на ремотной стороне. То, что быстрее или
> IL> сравнимо с сеткой (например RAM, NVM), надо использовать на локальной
> IL> стороне.
>
> мне кажется ты даже не задумался над моим возражением
>

А, в смысле что все равно читать из SSD? Ну так читателей-то несколько.
Естественно что если кеш на локальной стороне, то будет быстрее. Но на
ремотной стороне оно имеет больше смысла. В предположении что SSD
ограниченное количество и его надо беречь.

Это тезис storage vendor-ов, используемый для оправдания засовывания
флеша в array вместо того, чтобы засунуть его в хост клиента.

Может быть правильнее описывать то, что я называю remote caching "SSD
tiering", а local caching "SSD caching"?

--
ilya

[Slawa Olhovchenkov]

Ilya L <n...@interested.com> wrote:

IL> On 8/9/15 4:21 AM, Dmitry Krivitsky wrote:

>>> что-то я не понимаю этих рассуждений. можешь раскрыть?
>>> да, один обычный SSD медленней 10G сетки.
>>
>> http://www.intel.com/content/www/us/en/solid-state-drives/solid-state-drives-dc-p3700-series.html
>>
>> Это медленнее сетки?
>>

IL>
IL> Естественно, я имел ввиду SATA/SAS SSDs. Хотя PCIe все равно медленне,
IL> чем 40Gbit network.

чё? а куда 40G nic втыкают? не в PCIe, что ли?
а чего тогда у меня 40G в PCIe воткнута?

IL> Чем быстрее storage, тем выгоднее ее держать ближе к консумеру.

очень однобокий подход.

--
Slawa Olhovchenkov

[Ilya L]

On 8/9/15 1:31 PM, Slawa Olhovchenkov wrote:

>>> http://www.intel.com/content/www/us/en/solid-state-drives/solid-state-drives-dc-p3700-series.html
>>>
>>> Это медленнее сетки?
>>>
> IL>
> IL> Естественно, я имел ввиду SATA/SAS SSDs. Хотя PCIe все равно медленне,
> IL> чем 40Gbit network.
>
> чё? а куда 40G nic втыкают? не в PCIe, что ли?
> а чего тогда у меня 40G в PCIe воткнута?

Естественно, я имел ввиду PCIe *SSD*. Конкретно на вот этом интеловский
флеше написано 2.8GB, если верить спеку.

А куда, кстати, 100GBe втыкают? А, в PCIe 2.0.

> IL> Чем быстрее storage, тем выгоднее ее держать ближе к консумеру.
>
> очень однобокий подход.
>

Это упрощенный тезис в пользу перехода от SAN/NAS в hyper-converged в
условиях изобилия быстрого storage.

--
ilya

[Ilya L]

On 8/9/15 1:45 PM, Ilya L wrote:
> On 8/9/15 1:31 PM, Slawa Olhovchenkov wrote:
>
>>>> http://www.intel.com/content/www/us/en/solid-state-drives/solid-state-drives-dc-p3700-series.html
>>>>
>>>>
>>>> Это медленнее сетки?
>>>>
>> IL>
>> IL> Естественно, я имел ввиду SATA/SAS SSDs. Хотя PCIe все
>> равно медленне,
>> IL> чем 40Gbit network.
>>
>> чё? а куда 40G nic втыкают? не в PCIe, что ли?
>> а чего тогда у меня 40G в PCIe воткнута?
>
> Естественно, я имел ввиду PCIe *SSD*. Конкретно на вот этом
> интеловский флеше написано 2.8GB, если верить спеку.
>
> А куда, кстати, 100GBe втыкают? А, в PCIe 2.0.
>

100Gbe. А то опять прикопаются.

[Slawa Olhovchenkov]

Ilya L <n...@interested.com> wrote:

IL> On 8/9/15 11:39 AM, Slawa Olhovchenkov wrote:

>> IL> Что Diablo MSC это NAND flash, который вставляется в DIMM slot и имеет
>>
>> по данному линку эта информация отсутствует.
>>

IL> У вас там гугл импортнозаместили?

гугл сам себя давно импортозаместил.
кроме всяго говна про игрушку он мне ничего не предлагал.

IL> http://www.storagereview.com/diablo_s_mcs_architecture_integrated_into_lenovo_x6_servers

>> IL> DDR3 interface. Поддерживается в массовом продуктах ESXi и VSAN.
>>
>> современные сервера идут с DDR4.
>> гугл не находит ни одного предложения по продаже Diablo MSC.
>> на сайте даже даташитов нет.

IL> В retail оно называется Lenovo eXFlashTM DIMM и SanDisk ULLtraDIMMTM.

два килобакса за 400ГБ?
140K/44KIOPS?
880MBs/600MBs?
0.1ms задержка чтения?

HGST SSD800MH выглядит даже быстрее.
собственно, схера бы быть чуду? там же внутри та же самая технология и физика.

IL> http://www.diablo-technologies.com/server-vendor/
IL> Щас будут обвинять меня в том, что я продавец Леново...


--
Slawa Olhovchenkov

[Slawa Olhovchenkov]

Ilya L <n...@interested.com> wrote:

IL> On 8/9/15 11:41 AM, Slawa Olhovchenkov wrote:

>>>> типа по сети спросить быстрее чем с SSD прочитать?
>>>> а по сети они откуда возьмутся? еще раз по сети?
>>>> или с HDD вычисляться будут? или с тех же SSD?
>>
>> IL> С SSD, используемых в качестве кеша для данных, хранимых на диске. (Или
>> IL> с быстрых SSD, используемых в качестве кеша для медленных SSD).
>>
>> IL> То, что медленне сетки (например, SSD, вставленное в SATA), надо
>> IL> использовать для кеширования на ремотной стороне. То, что быстрее или
>> IL> сравнимо с сеткой (например RAM, NVM), надо использовать на локальной
>> IL> стороне.
>>
>> мне кажется ты даже не задумался над моим возражением
>>

IL> А, в смысле что все равно читать из SSD? Ну так читателей-то несколько.
IL> Естественно что если кеш на локальной стороне, то будет быстрее. Но на
IL> ремотной стороне оно имеет больше смысла. В предположении что SSD
IL> ограниченное количество и его надо беречь.

расставляя SSD локально их можно поставить больше (суммарно), при этом соседние
читатели не будут вымывать твое.

IL> Это тезис storage vendor-ов, используемый для оправдания засовывания
IL> флеша в array вместо того, чтобы засунуть его в хост клиента.

короче, я бы сказал что общего решения не существует и все очень сильно зависит от профиля
нагрузки. но 40Г сетевуха стоит как 8 SSD объемом 3.5ТБ с LSI2008. и это без учета стоимости
коммутатора. что, в общем, тоже вполне себе фактор.

ну и материнок с 40Г LOM я пока не видел, в отличии от 10Г. опять же, тут есть неявное предположение,
что 40Г сервера не будет насыщено, как и вообще его способность отдать запрошенное.
мне не очевидно чего бы это было верно.

так что если есть задача в которой горячие данные влезут в память толстого сервера, обрабатываться
будут на мелких нодах с 40Г LOM -- да, выгодней будет по сети дергать.

IL> Может быть правильнее описывать то, что я называю remote caching "SSD
IL> tiering", а local caching "SSD caching"?

ты эта, не выебывайся, ты русский языка пользуй.

--
Slawa Olhovchenkov

[Slawa Olhovchenkov]

Ilya L <n...@interested.com> wrote:

IL> On 8/9/15 1:31 PM, Slawa Olhovchenkov wrote:

>>>> http://www.intel.com/content/www/us/en/solid-state-drives/solid-state-drives-dc-p3700-series.html
>>>>
>>>> Это медленнее сетки?
>>>>
>> IL>
>> IL> Естественно, я имел ввиду SATA/SAS SSDs. Хотя PCIe все равно медленне,
>> IL> чем 40Gbit network.
>>
>> чё? а куда 40G nic втыкают? не в PCIe, что ли?
>> а чего тогда у меня 40G в PCIe воткнута?

IL> Естественно, я имел ввиду PCIe *SSD*. Конкретно на вот этом интеловский
IL> флеше написано 2.8GB, если верить спеку.

да, когда я присматривался, то для насыщения 40Г надо было бы мне брать два таких.
но ценник отвратил в пользу 8 обычных SATA SSD.

IL> А куда, кстати, 100GBe втыкают? А, в PCIe 2.0.

пока а) не видел б) не вижу смысла на современном железе
(с учетом памяти/QPI/колчиества PCIe lane).

>> IL> Чем быстрее storage, тем выгоднее ее держать ближе к консумеру.
>>
>> очень однобокий подход.
>>

IL> Это упрощенный тезис в пользу перехода от SAN/NAS в hyper-converged в
IL> условиях изобилия быстрого storage.

все распределенные FS, про которые я слышал -- а) очень медленные б) ломаются.

--
Slawa Olhovchenkov

[Sergey Babkin]

Погодите, так вы что, не про новое 3D Xpoint беседуете?

-СБ

[Sergey Babkin]

On 08/09/2015 11:40 AM, Ilya L wrote:
> On 8/9/15 4:21 AM, Dmitry Krivitsky wrote:
>
>>> что-то я не понимаю этих рассуждений. можешь раскрыть?
>>> да, один обычный SSD медленней 10G сетки.
>>
>> http://www.intel.com/content/www/us/en/solid-state-drives/solid-state-drives-dc-p3700-series.html
>>
>>
>> Это медленнее сетки?
>>
>
> Естественно, я имел ввиду SATA/SAS SSDs. Хотя PCIe все равно медленне,
> чем 40Gbit network.

Осталось вспомнить, через какой интерфейс подключается сетевая плата.

-СБ

[Dmitry Krivitsky]

On 8/9/2015 2:40 PM, Ilya L wrote:
> On 8/9/15 4:21 AM, Dmitry Krivitsky wrote:
>
>>> что-то я не понимаю этих рассуждений. можешь раскрыть?
>>> да, один обычный SSD медленней 10G сетки.
>>
>> http://www.intel.com/content/www/us/en/solid-state-drives/solid-state-drives-dc-p3700-series.html
>>
>> Это медленнее сетки?
>
> Естественно, я имел ввиду SATA/SAS SSDs.

Не вижу в этом ничего естественного.
Что внутри этой хрени, которую ты рекламируешь - все тот же флеш?
Если да, то это SSD, независимо от того, какой там у него интерфейс.
Со всеми своими особенностями, в виде ограниченного количества
стираний, необходимости wear leveling, TRIM, overprovisioning и все такое.
Это ж все не с интерфейсом связано, а с физикой того, что внутри.

> Хотя PCIe все равно
> медленне, чем 40Gbit network.

А если PCIe v4 x16 ? :-)

[Sergey Babkin]

On 08/09/2015 12:18 PM, Ilya L wrote:
> On 8/9/15 4:34 AM, Sergey Babkin wrote:
>
>>> Объясни, чем локальные файлы лучше, чем memcached для кеширования
>>> полученных из Кассандры данных кластером горизонтально заскейленные
>>> инстансов.
>>
>> Размером. Ценой. Отсутствием нагрузки на сеть, которая является узким
>> местом.
>
> И то, что разные запросы в одной сессии приходят на разные инстансы, это
> ничего?

Ась?

>
>>> Ну щас. SSD медленнее, чем локальная сеть и поэтому используется для
>>> кеширования на той стороне, где данные лежат на диске.
>>
>> Память, Карл, память!
>>
>
> Речь шла о том, где лучше использовать SSD и где лучше использовать
> "память". Тезис состоит в том, что SSD нужно/можно использовать over the
> network, а "память" нужно использовать локально. Что приводит к
> необходимости редизайна storage systems при переходе с SSD на NVM.

Тезис в том, что новый 3D Xpoint по скорости обещает быть почти как RAM, только
non-volatile, и гораздо больше размером.

>> Слово BigTable слышал? Это тот самый распределенный key-value store. Его
>> можно использовать напрямую или поверх него есть интерфейсы файловой
>> системы и
>> реляционной базы (megastore/datastore/f1).
>
> Мне казалось, что BT/GFS не поддерживают репликацию по линкам с высоким

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

> latency. И partitioning не поддерживает. Если поддерживает, но не совсем

Не уверен, что ты имеешь в виду под partitioning. Цель - наоборот
предотвратить разделение зеркал. Если часть кластеров станет недоступными,
они отключатся. Какая связная часть толще - та и побеждает.
Для этого в частности и используется lock manager.

> понятно, как можно поверх положить layer, дающий ACID семантику.

Ну, оно может быть Секретно, так что рассказывать не буду. Но коряво
сделано, конечно. Вот видимо поэтому в новой версии уже есть родные
транзакции.

> Мне надо, чтобы можно было читать и писать одни и те же данные в разных
> datacenters, расположенных в 100 ms друг от друга. При этом потеря
> connectivity между datacenters не должна приводить к отсутствию
> возможности читать-писать. Можно это сделать с помощью BT/F1?

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

>> В megastore/datastore проблема транзакций решалась совершенно
>> монструозным
>> способом.
>>
>> Приложение пишется в виде stateless программ и отдельно слоя хранения
>> данных. Слой хранения данных - географически распределенный, с копиями
>> данных
>> в разных кластерах (и BigTable дает избыточность с устойчивостью
>> к потере машин в одном кластере).
>
> Это как оно решалось до того, как на BigTable положили что-то более
> удобное и транзакционное?

Подсказка: BigTable - это не просто KV-store, а еще и с историей, дающей
eventual consistency. На каждый ключ хранится множество значений с
таймстампами. Старые значения периодически вычищаются сисадминами.
Ну, и на самом деле там есть множество дополнительных фич. Начиная от
дополнительных индексов и заканчивая хитрожопыми оптимизациями.

-СБ

[Sergey Babkin]

Действительно, красиво для джойнов по равенству.

-СБ

[Ilya L]

On 8/9/15 2:19 PM, Slawa Olhovchenkov wrote:

> IL> В retail оно называется Lenovo eXFlashTM DIMM и SanDisk ULLtraDIMMTM.
>
> два килобакса за 400ГБ?
> 140K/44KIOPS?
> 880MBs/600MBs?
> 0.1ms задержка чтения?
>
> HGST SSD800MH выглядит даже быстрее.
> собственно, схера бы быть чуду? там же внутри та же самая технология и физика.
>

Вроде в latency должна быть разница. Что-то не могу найти сколько оно
для SSD800MH, в районе 5-10 ms? Плюс интерфейс другой кардинально с
точки зрения хоста. Параллельный vs serial, deeper queues, никаких TRIM.

Я не апологет Diablo. Просто был вопрос про наличие продуктов в DIMM
формате, я разьяснил.

Но народ, вроде, пользует и (3rd party) девелоперы активно портят софт
под специфику NVM. Поэтому я думаю, что оно скоро пойдет в mainstream.
Не обязательно от Diablo, Intel XPoint должен появиться в дикой природе
в 2015.

--
ilya

[Ilya L]

On 8/9/15 2:30 PM, Slawa Olhovchenkov wrote:

> IL> А, в смысле что все равно читать из SSD? Ну так читателей-то несколько.
> IL> Естественно что если кеш на локальной стороне, то будет быстрее. Но на
> IL> ремотной стороне оно имеет больше смысла. В предположении что SSD
> IL> ограниченное количество и его надо беречь.
>
> расставляя SSD локально их можно поставить больше (суммарно), при этом соседние
> читатели не будут вымывать твое.

*** В предположении что SSD ограниченное количество и его надо беречь. ***

--
ilya

[Sergey Babkin]

Непонятно только, почему они ограничиваются 1:1 и 1:M. M:M тоже должно
делаться тем же способом.

-СБ

[Ilya L]

On 8/9/15 2:36 PM, Slawa Olhovchenkov wrote:

>
> IL> Это упрощенный тезис в пользу перехода от SAN/NAS в hyper-converged в
> IL> условиях изобилия быстрого storage.
>
> все распределенные FS, про которые я слышал

Нет там никаких FS и SQL тоже нет. Есть datastore, в котором хранятся
виртуальные диски. Распределенные по 64 хостам кластера. На которых
бегут VMs.

> -- а) очень медленные б) ломаются.

~7 миллионов IOPS (random reads), 2-3 ms latency.

--
ilya

[Ilya L]

On 8/9/15 4:49 PM, Sergey Babkin wrote:

>
> Погодите, так вы что, не про новое 3D Xpoint беседуете?
>

Не, Xpoint еще на завезли.

--
ilya

[Ilya L]

Да, я до этого неправильно сказал что trim не нужен. Нужен.

Честно говоря, хрен его знает, чем оно лучше. Вроде latency и
параллелилизм. Но я его не рекламирую. А констатирую что оно есть и
требует усилий для интеграции.

--
ilya

[Ilya L]

On 8/9/15 5:11 PM, Sergey Babkin wrote:
>>>> Объясни, чем локальные файлы лучше, чем memcached для кеширования
>>>> полученных из Кассандры данных кластером горизонтально заскейленные
>>>> инстансов.
>>>
>>> Размером. Ценой. Отсутствием нагрузки на сеть, которая является узким
>>> местом.
>>
>> И то, что разные запросы в одной сессии приходят на разные инстансы, это
>> ничего?
>
> Ась?
>

HTTP запросы. Приходят. Через load balancer. На разные инстансы. В
одной сессии. И для выполнения требуют. Одних и тех же. Данных.

Capisce?

>> Речь шла о том, где лучше использовать SSD и где лучше использовать
>> "память".
>

> Тезис в том, что новый 3D Xpoint по скорости обещает быть почти как RAM,
> только non-volatile, и гораздо больше размером.
>

Нагуглил Xpoint? Это хорошо.

>> Мне казалось, что BT/GFS не поддерживают репликацию по линкам с высоким
>
> Поддерживает.

В master-master или master-slave? Ссылку дай.

>> latency. И partitioning не поддерживает. Если поддерживает, но не совсем
>

> Не уверен, что ты имеешь в виду под partitioning.Цель - наоборот
> предотвратить разделение зеркал.

Я имел ввиду что BT не поддерживает availability during partitioning.

И таки да, в Треугольнике BigTable нарисована на CP axis. Опять "ась?"

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

Нет, такой футбол нам не нужен. Нужно Availability + Partition
Tolerance = AP axis.

Чтобы когда east отваливался от west, локальный production продолжал бы
работать на обоих сторонах, а не сосать лапу в minority partition.

>> Это как оно решалось до того, как на BigTable положили что-то более
>> удобное и транзакционное?
>
> Подсказка: BigTable - это не просто KV-store, а еще и с историей, дающей
> eventual consistency. На каждый ключ хранится множество значений с
> таймстампами. Старые значения периодически вычищаются сисадминами.
> Ну, и на самом деле там есть множество дополнительных фич. Начиная от
> дополнительных индексов и заканчивая хитрожопыми оптимизациями.

Да вроде знаю я все это на уровне просмотра презентаций и митингов с
вашим Бревером. Только про eventual consistency не очень понятно.

Или имеется ввиду что в majority partition update будет сделан (через
Paxos), а minority будет read-only до воссоединения? А после
воссоединения получит апдейты из majority. И это ты называешь eventual
consistency?

Но я про интерфейс спрашивал, а не про фичи. Написано, что API у
Spanner это "что-то вроде SQL". Это оно? Или какой-то другой, более
продвинутый layer есть on top?

--
ilya

[Ilya L]

On 8/9/15 5:54 PM, Sergey Babkin wrote:

>> Действительно, красиво для джойнов по равенству.
>
> Непонятно только, почему они ограничиваются 1:1 и 1:M. M:M тоже должно
> делаться тем же способом.

Cartesian product можно через reduce делать, gogle показывает простые
примеры.

Вот как сделать join по критерию < > я что-то не соображу...


Ну естественно легче всю эту реляционную арифметику делать в SQL. Надо
посмотреть на ваш ключ гаечный.

--
ilya