Ну плюс-минус наверное понятно, типа имеется в виду, что принцип работы по меткам, как у селинукса, но при этом наворочено не так, как у селинукса… Ну возможно, фиг знает. Но так-то ведь может эти мандаты даже можно и на селинуксе смоделировать правилами, принцип-то вроде тот же примерно — какие-то метки на файлах, какой-то контекст на процессах…
// даже чего-то про «лападулу» в документации селинукса пишут
Ну вот на мой, условно посторонний, взгляд пока вся эта теория выглядит как сферический конь в вакууме, практические преимущества которого не понятны. Мне не понятно, почему система с одним видом меток (парсек) вдруг должна оказаться безопаснее системы с другим видом меток (селинукс), если всё равно всё сводится к наличию проверок доступа в коде ядра.
Но самих-то уровня там по сути только два, юзер и админ. Разве нет? В линуксе тогда тоже можно сказать — высокий уровень это рут, низкий уровень это юзер. Но почему-то приводится в пример не линукс, а уак)
Думаю, что выражу общее мнение, если скажу, что в статье много воды и не хватает описания того, как все эти мандаты работают с точки зрения юзера и чем отличаются от селинукса и аппармора, чем удобнее там и т.п… Крайне маловероятно, что конечного юзера волнуют модели Бибы и Бобы и прочих ла-падулов) я лично 100500 раз слышал что в астре какие-то мандаты, но нафиг это надо и как это работает, так и не читал / не слышал ни разу.
Это что. Получается что это просто целочисленный атрибутик на каждом файле от 0 до 63 и распиханные по коду ядра сравнения, которые запрещают бинарям с циферкой выше читать файл с циферкой ниже? Кстати а случайно то же самое на селинуксе аналогично не реализуется ли? Там же тоже атрибутики. Контекст селинукса это не аналог мандата ли в некотором роде?
ЗЫ и да, винду с её юаком приводить в пример это вообще ржака.
если файл >= 4 мб, то он в любом случае порежется на куски по 4 мб. т.е. одному S3 объекту будет соответствовать много RADOS объектов :-).
миллионы загрузок одного файла в секунду — это всё-таки не задача S3, кэшем каким-то надо накрыть, в том же омозоне тупо на запросах и трафике разоришься…
но так-то замечание верное — если какой-то гад будет долбить один и тот же ключ многократно — это в цефе не масштабируется.
с другой стороны — а масштабируется ли в амазоне? вот в чём вопрос. вот можно было бы по ним бахнуть какой-нибудь бенчилкой в один ключ, например, для интереса. хотя там небось могут запросы в секунду лимитироваться и тогда ни фига не поймёшь…
Про чтение с primary правда, но там это не мешает, т.к. шардируется в разрезе PG, а PG дофига и на каждом OSD размещается их 100 штук примерно обычно, и для части он оказывается primary. Поэтому там и смысла нет читать с реплик, и там все диски утилизируются. Сделать чтение с реплик напрямую наверное как раз не получится, т.к. состоянием владеет primary, и как раз он знает, вообще откуда читать, если объект сейчас перемещается.
Метаданные реплицировать асинхронно т.к. это БД, чтобы не тормозить ее, те же листинги... а данные пишутся все равно относительно долго и там есть время сходить на другие реплики. Ну или да, почему нет такого варианта, что амазон тупо сделал синхронную репликацию таки и в метабазах S3, когда перешел на консистентность? И читает себе дальше с реплик, просто они теперь синхронные. Вроде никаким уликам это не противоречит, репликация между бакетами это другое :-)
Ну просто иначе надо организовывать какую то очередь асинхронной репликации данных, кэши вот эти извратные и т.п., неудобно как-то.
Не, может это и правда, что у амазона такое наделано, я свечку не держал. Но звучит довольно извратно
ну меня как-то это не убеждает. могут данные реплицироваться синхронно например (сразу писаться на несколько дисков), а метаданные в репликах БД доползать асинхронно :-) или например могли просто с переходом на консистентность просто поменять архитектуру, может там теперь цефоподобное нечто внутри? :-)
> Amazon Replication Time Control
> В таких условиях единственный способ узнать, где находится последняя версия объекта — собирать эту информацию на один или несколько каталогов.
Вы уверены, что не путаете (вероятно синхронную) внутреннюю репликацию в рамках бакета для обеспечения избыточности и (явно асинхронную) репликацию между бакетами, видимо для обеспечения геораспределённости?)
Ути пути. Выводов верных нет. А зарплат по 30 тыр в МГУ тоже нет?
И в КБ, которые беспилотниками занимаются. Про которые та же так называемая вами «сетка каналов» писала. Прямо со скринами с hh.ru
Вы ещё про вузы вспомните. Про зарплаты преподавателей никто уже и не вспоминает похоже, т.к. бессмысленно. :-) я каждый раз вспоминаю, когда вижу подобный материал. Доцент в МГУ — 30000 рублей. И это ТИПА ведущий вуз страны. Что же тогда в остальных, страшно представить.
Ну просто их и в инете нигде нет, вроде алгоритм неплохой, но юзать без исходников никто ж его не будет :-)
Ну, хорошо, что наконец-то в ЛабКГММ занимаются алгоритмами сжатия. А не видеофильтрами для самсунга, бгг ))). // когда в 2005 выбирал кафедру — не пошёл на АСВК, потому что мне сообщили, что учиться мы не будем, а будем видеофильтры типа «мультфильм» для самсунга писать)
мне вот почему-то кажется, что там основной профит производительности как раз из-за интегрированной памяти
ну т.е. не верится в то, что просто архитектура ARM vs x86 настолько оптимальнее, т.к. на других-то ARM-ах существующих это не так
интересно, исследует ли кто-то эту гипотезу
ну и соответственно, если это вдруг правда — то ждём повторения «успеха» от других производителей
Простите, я всё равно не верю, что из ниоткуда может появиться компания, которую никто не знает, но при этом она, оказывается, уже 15-20 лет пилит операционную систему, компилятор, GUI, виртуализацию, реализацию .NET (!!!) и так далее и тому подобное. И у неё на это откуда-то есть деньги при полной очевидности, что пользоваться массово никто этим не будет.
Да и никто, по-видимому, не верит. )))
Десятки человеколет это возможно (и, кстати, это не много), но есть подозрение, что эти десятки ушли на хитрую перебивку бейджиков в готовых компонентах (и, возможно, переписывание какой-то их части). Возможно, из утечек кода винды, возможно, из GPL-ного софта. Код никому не показывают, проверить никто не может.
«Разработчик уверен, что ОС безопасна» — это вообще смешно. Уязвимости не специально же добавляются, они сами вылезают.
В общем, выложите в опенсорс — мы все дружно проверим, возьмём свои слова обратно и ещё похвалим. Всё равно разницы никакой нет, коммерческий успех продукту в закрытом виде не светит )
1) не всегда
2) не всегда — в том числе не на всех клиентских есть SLC кэши — в том числе на части SLC кэш можно даже отключить конфигурацией прошивки и перепрошивкой — лично такое делал. и наоборот, на каких-то «серверных» SLC кэш может быть.
3) а вот конденсаторы — это стопроцентная тема, мы уже в цефочате про них года 3 рассказываем всем. вот, наконец и досюда долетело) правда про L2P опять не совсем верно, как серверные, так и клиентские диски кэшируют всё подряд, а не только маппинги. просто серверные могут вообще ничего не сбрасывать во флеш при fsync — ни данные, ни метаданные. а, и да, на самых дешёвых «серверных» Intel DC конденсаторов нет.
Ну про сертифицированные то понятно, что это основной смысл существования астры, интересовало что с точки зрения юзера)
// даже чего-то про «лападулу» в документации селинукса пишут
Возможно какие-то преимущества есть, я не отрицаю, но чтобы это юзер понял, это надо разъяснить) может, там, с точки зрения удобства эксплуатации. Но вот я даже щас документацию какую-то нашёл и почитал astralinux.ru/products/astra-linux-special-edition/relizyi/smolensk/dokumentacziya/rukovodstvo-po-kompleksu-sredstv-zashhityi.-chast-1.pdf и как-то не возникло ощущения простоты)
Это что. Получается что это просто целочисленный атрибутик на каждом файле от 0 до 63 и распиханные по коду ядра сравнения, которые запрещают бинарям с циферкой выше читать файл с циферкой ниже? Кстати а случайно то же самое на селинуксе аналогично не реализуется ли? Там же тоже атрибутики. Контекст селинукса это не аналог мандата ли в некотором роде?
ЗЫ и да, винду с её юаком приводить в пример это вообще ржака.
миллионы загрузок одного файла в секунду — это всё-таки не задача S3, кэшем каким-то надо накрыть, в том же омозоне тупо на запросах и трафике разоришься…
но так-то замечание верное — если какой-то гад будет долбить один и тот же ключ многократно — это в цефе не масштабируется.
с другой стороны — а масштабируется ли в амазоне? вот в чём вопрос. вот можно было бы по ним бахнуть какой-нибудь бенчилкой в один ключ, например, для интереса. хотя там небось могут запросы в секунду лимитироваться и тогда ни фига не поймёшь…
Про чтение с primary правда, но там это не мешает, т.к. шардируется в разрезе PG, а PG дофига и на каждом OSD размещается их 100 штук примерно обычно, и для части он оказывается primary. Поэтому там и смысла нет читать с реплик, и там все диски утилизируются. Сделать чтение с реплик напрямую наверное как раз не получится, т.к. состоянием владеет primary, и как раз он знает, вообще откуда читать, если объект сейчас перемещается.
Метаданные реплицировать асинхронно т.к. это БД, чтобы не тормозить ее, те же листинги... а данные пишутся все равно относительно долго и там есть время сходить на другие реплики. Ну или да, почему нет такого варианта, что амазон тупо сделал синхронную репликацию таки и в метабазах S3, когда перешел на консистентность? И читает себе дальше с реплик, просто они теперь синхронные. Вроде никаким уликам это не противоречит, репликация между бакетами это другое :-)
Ну просто иначе надо организовывать какую то очередь асинхронной репликации данных, кэши вот эти извратные и т.п., неудобно как-то.
Не, может это и правда, что у амазона такое наделано, я свечку не держал. Но звучит довольно извратно
ну меня как-то это не убеждает. могут данные реплицироваться синхронно например (сразу писаться на несколько дисков), а метаданные в репликах БД доползать асинхронно :-) или например могли просто с переходом на консистентность просто поменять архитектуру, может там теперь цефоподобное нечто внутри? :-)
> В таких условиях единственный способ узнать, где находится последняя версия объекта — собирать эту информацию на один или несколько каталогов.
Вы уверены, что не путаете (вероятно синхронную) внутреннюю репликацию в рамках бакета для обеспечения избыточности и (явно асинхронную) репликацию между бакетами, видимо для обеспечения геораспределённости?)
И в КБ, которые беспилотниками занимаются. Про которые та же так называемая вами «сетка каналов» писала. Прямо со скринами с hh.ru
Ну, хорошо, что наконец-то в ЛабКГММ занимаются алгоритмами сжатия. А не видеофильтрами для самсунга, бгг ))). // когда в 2005 выбирал кафедру — не пошёл на АСВК, потому что мне сообщили, что учиться мы не будем, а будем видеофильтры типа «мультфильм» для самсунга писать)
>На гипервизоре выделение ресурсов виртуальным машинам происходит, как правило, с переподпиской.
А в калькуляторе у вас светится гордое "Гарантированная доля vCPU = 100%" ;-)
ну т.е. не верится в то, что просто архитектура ARM vs x86 настолько оптимальнее, т.к. на других-то ARM-ах существующих это не так
интересно, исследует ли кто-то эту гипотезу
ну и соответственно, если это вдруг правда — то ждём повторения «успеха» от других производителей
Да и никто, по-видимому, не верит. )))
Десятки человеколет это возможно (и, кстати, это не много), но есть подозрение, что эти десятки ушли на хитрую перебивку бейджиков в готовых компонентах (и, возможно, переписывание какой-то их части). Возможно, из утечек кода винды, возможно, из GPL-ного софта. Код никому не показывают, проверить никто не может.
«Разработчик уверен, что ОС безопасна» — это вообще смешно. Уязвимости не специально же добавляются, они сами вылезают.
В общем, выложите в опенсорс — мы все дружно проверим, возьмём свои слова обратно и ещё похвалим. Всё равно разницы никакой нет, коммерческий успех продукту в закрытом виде не светит )
2) не всегда — в том числе не на всех клиентских есть SLC кэши — в том числе на части SLC кэш можно даже отключить конфигурацией прошивки и перепрошивкой — лично такое делал. и наоборот, на каких-то «серверных» SLC кэш может быть.
3) а вот конденсаторы — это стопроцентная тема, мы уже в цефочате про них года 3 рассказываем всем. вот, наконец и досюда долетело) правда про L2P опять не совсем верно, как серверные, так и клиентские диски кэшируют всё подряд, а не только маппинги. просто серверные могут вообще ничего не сбрасывать во флеш при fsync — ни данные, ни метаданные. а, и да, на самых дешёвых «серверных» Intel DC конденсаторов нет.