Pull to refresh
37
0
Владимир@larrabee

DevOps

Send message
6к iops на 6 red дисках в рейд 5? Серьезно? На кэше можно и 60к намерить. 6 х 2 tb wd red в рейде 10 у меня выдают около 500 iops при латенси 40 мс. Для теста лучше отдать масив по iscsi и провести тест fio с линукс хоста не забывая контролировать латенси.
Отличается конструкцией, в маковском куллере (как и в остальных ноутбучных) вентилятор (а точнее турбина) только переносит воздух от радиатора. В этом же лопасти не только гоняют воздух, но и сами являются радиатором.
ИМХО статья бесполезна. Тоже самое на technet, только более подробно и без картинок. А уж сколько подобных статей в интернете не счесть
зачем использовать биткоинты и им подобную криптовалюту, когда есть электронные деньги

Потому что, как уже написали выше биткоин (и прочие криптовалюты) позволяет не только платить онлайн, но и обладает некоторыми другими свойставами:
  1. Это отдельная валюта, со всеми ее плюсами и минусами.
  2. Анонимность транзакций. Хотя в биткойне далеко и не обсолютная.
  3. Отсутвие центрального регулятора. Не у кого нет доступа к печатному станку, что бы делать с валютой то, что заблогарассудится.

Ведь это спекуляция чистой воды.

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

Контролируемый правилами системы, которым все ее участники подчиняются.
Там даже в случае чего можно найти любого крайнего, если на то потребуется «политическая» воля.

В случае чего любого крайнего можно найти и без криптовалют. Уж мы то должны знать, в России живем…
И с точки зрения безопасности экономики — правильные запреты! Китаёзы с индусами тоже молодцы, что запретили.

С точки зрения безопастности экономики надо запрячь всех нас пахать поле по 16 часов в день. Тогда экономика точно будет в порядке. Не ради экономики все делается, ради людей, которые на эту экономику работают. Ну и нашли конечно примеры благополучных стран. Китай, где власть держит народ в ежовых рукавицах, не давая раскрыть рта и нищая Индия. На это нам стоит равняться?
А ещё не понятно чем мешает этот правильный запрет отдельным недовольным.

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

Так может что то не так в этой вашей экономике. Может пришла пора переходить к децентрализованным валютам, а не реанимировать текущую (я не призываю все сломать, но мне кажется необходимость изменений назревает давно).
Потому что тогда возникнет проблема с баллансировкой диска и сильными вибрациями. Такой большой (5.25) диск не сможет работать на скорости 7200 или 5400 об/мин. при текущей плотности записи. Придется либо снижать скорость вращения либо плотность. Если снижаем плотность записи, то вся затея вообще бесполезна. Если снижаем скрость вращения получаем ЖД с большой емкостью и ужастными скростными характеристиками. Вам например нужен диск, заполнять который данными придется неделями, а что-бы поработать с данными предварительно скопировать их на более быстрый носитель?
Сейчас 2.5 диски обеспечивают пожалуй большую плотность записи (на см^3).
MS, IBM, HP, Одноклассники

Этот ряд выглядит немного странно. Может тогда Mail.ru, а не одноклассники?
Спасибо. Я как раз использовал РО снапшоты.
Я же не говорю, что нельзя использвать в проде, я говорю, что можно, но с головой. ;)
Фейсбук пока начал только тестовое использование. Про гугл ничего быстро не нагуглилось.
Восстановление BTRFS это песня. Есть там ошибка, что то вроде «error read chunk root» при которой утилиты восстановления ничего не видят и не восстанавливают. У меня она ломалась несколько раз и каждый раз с этой ошибкой.
История с РО разделом произшла на 3.16-3.17, не исключено, что виновато было включенное сжатие.
С Btrfs нужно быть аккуратным. В ядро 3.16 (или 3.17) прилетел баг, из-за которого система падает в кернел паник при использовании сжатия. Так-же бывает ФС ломается после нескольких хард выключений подряд. Ломается до не восстановимого состояния. Один раз было такое- в нормально работающей системе корень вдруг перемонтировался в РО, после перезагрузки ФС была сломана, восстановлению не подлежала.
Да, все вышесказанное приключилось со мной на Arch Linux, ядра всегда последние. Так что если и использовать в проде BTRFS, то я порекомендовал бы какую нибудь убунту 14.04 (т.к. имеет свежее, но достаточно стабильное ядро), ОБЯЗАТЕЛЬНО иметь бэкап и не забывать, что данная ФС может похерить ваши данные.
З.Ы. В последних ядрах нет изменений BTRFS, кто нибудь знает продолжает ли Oracle разработку, или она заглохла?
А некоторое оборудование и 16К фреймы поддерживает
Видимо потому, что в странах с неразвитой медициной люди откидывают копыта от других заболеваний и не успевают умереть от рака.
Учится чему то новому никто не против. Но создалось впечатление, что ваш коллега не читал стать и быстренько накатал рекламный коммент.

если у нас есть СУБД или другое ПО, которое активно использует собственный кэш на запись, то перед бэкапом его нужно попросить сбросить кэш и заморозить запись на диск, иначе данные-то в снэпшот попадут, но не те

Еще раз: проблема в консистентности данных на диске. Снапшот позволяет получить консистентые данные на уровне блочного устройства или ФС, но это совершенно не значит, что данные будут консистентны на уровне приложения. Что бы они были консистентны приложение нужно оповестить о снятии снапшота (как это делает VSS), что бы оно сбросило кэши и тд. Собственно об этом и статья.
Консистентность для групп ВМ это хорошо, но сначала бы с одной ВМ разобраться.
Если мы друг друга не поняли и у вас эта проблема решена, то будет интересно узнать как.
Как я понимаю эта фича поддерживается только с qcow2 дисками?
Проблема не в производительности, проблема в консистентности данных. При вашем подходе запросто может оказаться, что в момент снятия снапшота часть новых данных в БД уже записана на диск, а часть еще в кэше. В итоге мы в бэкапе имеем неконсистентую базу данных. В худшем случае данные могут быть повреждены до полной бесполезности.
Автор поста как раз и говорит о способе сказать приложениям в госте, что нужно сброситьь кэши и приготовится к снятию снапшота, другой способ я описал в первом комментарии.
А чем снимать снапшот дело десятое.
А почему бы не делать суспенд гостя (все содержимое оперативной памяти, значения регистров ЦП и прочее записывается файлом на диск), потом сделать снапшот диска гостя, скопировать образ оперативной памяти и опять включить гостя?
Суспенд занимает около 5-10 сек., столько же на выход из него. В это время естественно гость будет не доступен, но после включения продолжит работать как ни в чем не бывало (только время нужно будет подкорректировать). В данном случае не важно какой гость, т.к. все делается на стороне QEMU. При восстановлении ВМ будет восстановлена в том же состоянии, в котором снимался бэкап.
Музыка тоже несет добро и радость. Представьте что вас на работе будут заставлять в хоре петь, а если плохо поешь, то лишают премии. Понравится такая обязаловка, несущая радость и добро?
Конечно. Как иначе твитнуть «Жителям города ХХХ до испарения осталось 6 минуть. Мира всем»
А по делу в статье же написано, что защищать планируетсясопровождающую инфраструктуру, которая подключена к интернету и представляет определенную ценность (бухгалтерия, документооборот и тд).
Я правильно понял, что с 2009 года могли создаваться невалидные резервные копии при использовании механизма CBT (который использует подавляющее большинство ПО), а заметили это только сейчас?
Никакого централизованного управления тут нет и насколько я понял из комментариев нет даже встроенного планировщика заданий. На серверах конечно можно использовать, но оптимально ли это…

Information

Rating
Does not participate
Location
Санкт-Петербург, Санкт-Петербург и область, Россия
Registered
Activity