Тут возможен гибридный подход. Сам nextcloud на домашнем сервере, а в облаке копеечная виртуальная машина с внешним IP и защитой от DDoS, которая через постоянный тоннель редиректит трафик на домашний сервер.
Но, вообще, выставлять подобный сервис наружу немного опасно. Я предпочитаю все-же его прятать за VPN, запущенный на той же виртуалке.
Вы задали вопрос не мне, но, наиболее вероятным видится сценарий, при котором станет невозможно установить обновления даже оффлайн, или активировать систему на новом сервере.
То есть, процесс "умирания" облака растянется во времени. Но, на горизонте 2-3 года без поддержки, обновлений и новых серверов оно неизбежно умрет.
То, что он пока есть, это, конечно, хорошо. Но, санкции то накладывают, по сути, не на вас, а на МС. Им запрещают с вами работать. Пока что, только напрямую, а они просто исполняют. В определенный момент, такие схемы поставки могут тоже запретить, и канал снова исчезнет.
МС, видимо, заинтересован в том, чтобы не потерять рынок совсем, потому они с вами продолжают работать, но, не похоже, что при принятии очередных ограничений, их кто-то спрашивает.
В общем, такая схема не надежна. И, исключительно как личное мнение, я бы, выбирая облако, расположенное в РФ физически или юридически, предпочел бы работающее на OpenStack (kvm) вместо Hyper-V или VMWare.
Да, это оно. Тоже удивился, когда прочитал, что их заменили давно. Где-то в первом десятке 2000-ых сдавал на них тестирование по дифурам. Преподаватель тогда тоже говорил, что машины на троичной логике работают.
Мне кажется, что представителям МС стоило бы тщательнее редактировать подобные сообщения, хотя, это, возможно, просто "трудности перевода", или авторство тех, кто "связывался с представителями". Все потому, что после прочтения этого жизнеутверждающего заявления остается один незакрытый вопрос:
А когда, собственно, будут блокировать продукты физических лиц?
Вы сравнили один из самых дешевых "энтерпрайз" SSD с одним из самых дорогих "консьюмерских", причем в супер-компактном форм-факторе NVM-E. Это не совсем честное сравнение.
И то, разница получилась почти в два раза.
У этого "энтерпрайзного", к сожалению, IOPS на запись в 10 раз меньше. Благодаря чему он использует более щадящие режимы записи в NAND, за счет чего достигается больший ресурс записи. NAND используется в накопителях практически одинаковый.
Для write-only кэша не лучший вариант, мягко скажем.
видим «база данных» — ставим dc ssd (а лучше всегда когда видим сервер).
Про базы данных, в общем, согласен, но, есть варианты. Например, взять пару энтерпрайзных NVM-E SSD сравнительно небольшого объема, и использовать их как write-only кэш с отложенной синхронизацией на основной массив. Если размер постоянно изменяемого пространства (записи) ограничен по сравнению с общим размером базы, то проблем с использованием консьюмерских SSD для редко изменяемых данных не будет. Отложенная синхронизация сильно уменьшает износ консьюмерских SSD.
Тут все, конечно, зависит от конкретного применения, и, под него надо рассчитывать размеры кэша, холодного хранилища и задержку синхронизации записи. Решение, однозначно, не универсальное. Но, при определенных условиях, рабочее.
Что касается пункта "всегда, когда видим сервер". То, тут я категорически не согласен. Использования в сервере бывают разные. И, в масштабе, переплачивать за энтерпрайз в случае массива для хранения, например, бэкапов или других WORM-данных будет явным перебором)
Емкий кэш нужен пользователям однозначно. Просто потому, что, как доказано на практике, есть куча приложений которые могут от этого получить огромный прирост производительности. Но, конечно есть и те приложения, которые не могут. Но, иметь возможность лучше, чем не иметь.
А, вот, производителю процессоров, как раз, не выгодно добавлять этот кэш в процессор, т.к. он увеличивает стоимость производства. Увеличивается площадь кристалла и уменьшается процент выхода годных кристаллов, что является особенно заметной проблемой для монолитного дизайна.
Кстати, в монолитном дизайне увеличение кэша тоже неизбежно приведет уменьшению частоты. Это не какая-то особенная фишка чиплетного/3D дизайна. Просто из-за увеличения тепловыделения за счет увеличения количества транзисторов.
Имея все сказанное выше, идея AMD сделать увеличенный кэш доступной опцией, причем, даже в десктопных процессорах, является оптимальной. У пользователей есть выбор, и, это очень хорошо!
В общем, я как пользователь на практике 64х-ядерного эппика в десктопном mid-tower корпусе с воздушным охлаждением, скажу, что ядра роляют. В том числе для сборки Ядра и Хромиума) А про то, что тепло ДОЛЖНО отводиться по всей площади процессора написано в прямо в "Installation Guide".
Если я правильно понял видео, то там проблема была с охлаждением. Из-за того, что контактная площадка теплоотвода водянки не покрывала всю площадь процессора, большая часть чиплетов с ядрами, скорее всего, просто, постоянно перегревалась. Для TR это является большой проблемой даже при 300W ограничении. Все потому, что один единственный плохо охлаждаемый чиплет может выделять до 150 ватт тепла и греть другие чиплеты, оставляя остальным чиплетам только половину теплопакета. При одинаковой частоте. Или снижая их частоту из-за нагрева.
В конце видео вроде сказано, что после обновления водянки эта проблема исчезла.
Вы правы, автор галочку позволяющую использовать протон для не поддерживаемых игр, возможно, не нашел, но, скорее всего, там про то, что в Стиме есть далеко не все игры.
В режиме точки доступа оно волне себе вроде работает) Проверено. Более "интересные штуки" я как-то не смотрел.
Беспроводной кластер, который можно разбросать по комнате и добавлять ноды на лету, это, конечно, удобно. Спору нет. Но, если уж собирать в корпус, то наверно можно все-таки и паяльником поработать). Не сложнее печати частей корпуса на 3D принтере.
Смысл пайки как раз в эстетике. "Чтоб просто работало" можно и без пайки собрать. Размеры красного адаптера точно соответствуют формату Zero если отпаять USB порт. Так что, кластер растет только по высоте. А в вырез для GPIO пинов удобно размещается антенна.
Хаб, кстати, может питаться от Orange Pi и, запитывать его напрямую через micro usb не обязательно. Но, конечно, желательно если больше двух агентов. Иначе не потянет по питанию. Но, он тут только для примера. Есть аналоги))
Есть много способов собрать кластер из одноплатников формата Pi Zero. Вопрос в том, как сделать общую сеть. Беспроводная сеть кажется мне не лучшим решением.
Мне более целесообразным показалось взять USB hub от Raspberry Pi Zero, вот такой:
Затем, перевести USB контроллер на agent-нодах в режим USB ethernet gadget и подпаять их к USB портам этого хаба.
Чтобы обойтись без пайки контактов на самих одноплатниках использовал вот такие адаптеры с отпаянным USB разъемом:
В качестве бонуса, - беспроводная сеть остается свободной, и, можно делать всякие интересные штуки с помощью беспроводных адаптеров не разбивая кластер.
Из недостатков, - USB порты доступны только на master-ноде. Но, в случае OrangePi Zero 2W это решается родным expansion board:
Что, заодно, дает и дополнительный ethernet порт.
В отличие от Raspberry PI Zero W/2W у Orange Pi Zero два USB-контроллера.
Есть вероятность, что эта функция может быть выключена до первой операции записи на носитель. Это нужно как раз чтобы была возможность вычитать неисправный SSD не убив его окончательно.
Как и написано выше, прошивка сама по себе данные в ячейках не обновляет, но, делает это при чтении. Так что, регулярно перечитывать данные крайне желательно. Иначе, через 3 года (вроде как срок гарантии этих дисков) данные будет уже не прочитать. Не совсем конечно, но медленное чтение и возможные ошибки, вероятны.
Но механизмы встроенные имеются. Если на SSD через SMART запланировать регулярно то, что у HDD называется extended self-test то, обновление будет происходить во время этого процесса.
SMART Self-test log structure revision number 1
Num Test_Description Status Remaining LifeTime(hours) LBA_of_first_error
# 1 Extended offline Completed without error 00% 34662 -
# 2 Extended offline Completed without error 00% 34494 -
# 3 Extended offline Completed without error 00% 34326 -
# 4 Extended offline Completed without error 00% 34158 -
# 5 Extended offline Completed without error 00% 33990 -
Это данные с 860 QVO возрастом 4 года, который еженедельно проходит такую проверку.
Шаг 1. Оптимизировать выражения.
Например, у вас куча условий по акциям, и, где-то в конце списка условий стоит наличие какого-то товара в корзине.
Если начать проверку условий с проверки этого товара, то остальные условия можно не проверять.
Это экономит время на бесполезной работе.
Шаг 2. Масштабирование / слияние выражений:
Предположим, у вас большая часть акций связана с наличием определенного товара.
Создаем таблицу товар->акции.
Пробиваем все товары из корзины по таблице в первую очередь.
Отправляем на дальнейшую обработку только акции из правой части таблицы.
Таким образом, мы за одну операцию проверили сразу все условия на "наличие товара" во всех акциях.
Шаг 3. Пишем свой оптимизатор
Автоматизация процесса на шаге 2.
Пишем свой собственный автоматический оптимизатор выражений / на основе статистики запросов.
Шаг 4. Компиляция в машинный код.
Например, средствами LLVM.
....
Имеем свой собственный оптимизирующий JIT компилятор DSL.
Тут возможен гибридный подход. Сам nextcloud на домашнем сервере, а в облаке копеечная виртуальная машина с внешним IP и защитой от DDoS, которая через постоянный тоннель редиректит трафик на домашний сервер.
Но, вообще, выставлять подобный сервис наружу немного опасно. Я предпочитаю все-же его прятать за VPN, запущенный на той же виртуалке.
Вы задали вопрос не мне, но, наиболее вероятным видится сценарий, при котором станет невозможно установить обновления даже оффлайн, или активировать систему на новом сервере.
То есть, процесс "умирания" облака растянется во времени. Но, на горизонте 2-3 года без поддержки, обновлений и новых серверов оно неизбежно умрет.
То, что он пока есть, это, конечно, хорошо. Но, санкции то накладывают, по сути, не на вас, а на МС. Им запрещают с вами работать. Пока что, только напрямую, а они просто исполняют. В определенный момент, такие схемы поставки могут тоже запретить, и канал снова исчезнет.
МС, видимо, заинтересован в том, чтобы не потерять рынок совсем, потому они с вами продолжают работать, но, не похоже, что при принятии очередных ограничений, их кто-то спрашивает.
В общем, такая схема не надежна. И, исключительно как личное мнение, я бы, выбирая облако, расположенное в РФ физически или юридически, предпочел бы работающее на OpenStack (kvm) вместо Hyper-V или VMWare.
Да, это оно. Тоже удивился, когда прочитал, что их заменили давно. Где-то в первом десятке 2000-ых сдавал на них тестирование по дифурам. Преподаватель тогда тоже говорил, что машины на троичной логике работают.
Если не ошибаюсь, у RUVDS хостинг на Hyper-V? В чем смысл тогда, если лицензию могут в любой момент отозвать?
Мне кажется, что представителям МС стоило бы тщательнее редактировать подобные сообщения, хотя, это, возможно, просто "трудности перевода", или авторство тех, кто "связывался с представителями". Все потому, что после прочтения этого жизнеутверждающего заявления остается один незакрытый вопрос:
Вы сравнили один из самых дешевых "энтерпрайз" SSD с одним из самых дорогих "консьюмерских", причем в супер-компактном форм-факторе NVM-E. Это не совсем честное сравнение.
И то, разница получилась почти в два раза.
У этого "энтерпрайзного", к сожалению, IOPS на запись в 10 раз меньше. Благодаря чему он использует более щадящие режимы записи в NAND, за счет чего достигается больший ресурс записи. NAND используется в накопителях практически одинаковый.
Для write-only кэша не лучший вариант, мягко скажем.
Про базы данных, в общем, согласен, но, есть варианты. Например, взять пару энтерпрайзных NVM-E SSD сравнительно небольшого объема, и использовать их как write-only кэш с отложенной синхронизацией на основной массив. Если размер постоянно изменяемого пространства (записи) ограничен по сравнению с общим размером базы, то проблем с использованием консьюмерских SSD для редко изменяемых данных не будет. Отложенная синхронизация сильно уменьшает износ консьюмерских SSD.
Тут все, конечно, зависит от конкретного применения, и, под него надо рассчитывать размеры кэша, холодного хранилища и задержку синхронизации записи. Решение, однозначно, не универсальное. Но, при определенных условиях, рабочее.
Что касается пункта "всегда, когда видим сервер". То, тут я категорически не согласен. Использования в сервере бывают разные. И, в масштабе, переплачивать за энтерпрайз в случае массива для хранения, например, бэкапов или других WORM-данных будет явным перебором)
Тогда, наверно, это все же "большой брат"/"старший брат"?
Не нужно изобретать. Этот собирательный образ давно существует. Зовется "дядя Сэм".
Емкий кэш нужен пользователям однозначно. Просто потому, что, как доказано на практике, есть куча приложений которые могут от этого получить огромный прирост производительности. Но, конечно есть и те приложения, которые не могут. Но, иметь возможность лучше, чем не иметь.
А, вот, производителю процессоров, как раз, не выгодно добавлять этот кэш в процессор, т.к. он увеличивает стоимость производства. Увеличивается площадь кристалла и уменьшается процент выхода годных кристаллов, что является особенно заметной проблемой для монолитного дизайна.
Кстати, в монолитном дизайне увеличение кэша тоже неизбежно приведет уменьшению частоты. Это не какая-то особенная фишка чиплетного/3D дизайна. Просто из-за увеличения тепловыделения за счет увеличения количества транзисторов.
Имея все сказанное выше, идея AMD сделать увеличенный кэш доступной опцией, причем, даже в десктопных процессорах, является оптимальной. У пользователей есть выбор, и, это очень хорошо!
В общем, я как пользователь на практике 64х-ядерного эппика в десктопном mid-tower корпусе с воздушным охлаждением, скажу, что ядра роляют. В том числе для сборки Ядра и Хромиума) А про то, что тепло ДОЛЖНО отводиться по всей площади процессора написано в прямо в "Installation Guide".
Если я правильно понял видео, то там проблема была с охлаждением. Из-за того, что контактная площадка теплоотвода водянки не покрывала всю площадь процессора, большая часть чиплетов с ядрами, скорее всего, просто, постоянно перегревалась. Для TR это является большой проблемой даже при 300W ограничении. Все потому, что один единственный плохо охлаждаемый чиплет может выделять до 150 ватт тепла и греть другие чиплеты, оставляя остальным чиплетам только половину теплопакета. При одинаковой частоте. Или снижая их частоту из-за нагрева.
В конце видео вроде сказано, что после обновления водянки эта проблема исчезла.
Вы правы, автор галочку позволяющую использовать протон для не поддерживаемых игр, возможно, не нашел, но, скорее всего, там про то, что в Стиме есть далеко не все игры.
В режиме точки доступа оно волне себе вроде работает) Проверено. Более "интересные штуки" я как-то не смотрел.
Беспроводной кластер, который можно разбросать по комнате и добавлять ноды на лету, это, конечно, удобно. Спору нет. Но, если уж собирать в корпус, то наверно можно все-таки и паяльником поработать). Не сложнее печати частей корпуса на 3D принтере.
Смысл пайки как раз в эстетике. "Чтоб просто работало" можно и без пайки собрать. Размеры красного адаптера точно соответствуют формату Zero если отпаять USB порт. Так что, кластер растет только по высоте. А в вырез для GPIO пинов удобно размещается антенна.
Хаб, кстати, может питаться от Orange Pi и, запитывать его напрямую через micro usb не обязательно. Но, конечно, желательно если больше двух агентов. Иначе не потянет по питанию. Но, он тут только для примера. Есть аналоги))
Есть много способов собрать кластер из одноплатников формата Pi Zero. Вопрос в том, как сделать общую сеть. Беспроводная сеть кажется мне не лучшим решением.
Мне более целесообразным показалось взять USB hub от Raspberry Pi Zero, вот такой:
Затем, перевести USB контроллер на agent-нодах в режим USB ethernet gadget и подпаять их к USB портам этого хаба.
Чтобы обойтись без пайки контактов на самих одноплатниках использовал вот такие адаптеры с отпаянным USB разъемом:
В качестве бонуса, - беспроводная сеть остается свободной, и, можно делать всякие интересные штуки с помощью беспроводных адаптеров не разбивая кластер.
Из недостатков, - USB порты доступны только на master-ноде. Но, в случае OrangePi Zero 2W это решается родным expansion board:
Что, заодно, дает и дополнительный ethernet порт.
В отличие от Raspberry PI Zero W/2W у Orange Pi Zero два USB-контроллера.
Есть вероятность, что эта функция может быть выключена до первой операции записи на носитель. Это нужно как раз чтобы была возможность вычитать неисправный SSD не убив его окончательно.
Как и написано выше, прошивка сама по себе данные в ячейках не обновляет, но, делает это при чтении. Так что, регулярно перечитывать данные крайне желательно. Иначе, через 3 года (вроде как срок гарантии этих дисков) данные будет уже не прочитать. Не совсем конечно, но медленное чтение и возможные ошибки, вероятны.
Но механизмы встроенные имеются. Если на SSD через SMART запланировать регулярно то, что у HDD называется extended self-test то, обновление будет происходить во время этого процесса.
Это данные с 860 QVO возрастом 4 года, который еженедельно проходит такую проверку.