Если сравнивать со списком, который Gartner опубликовал год назад, то из списка технологий исчезли: Big Data, серверные технологии «вычислений в RAM», Enterprise App Stores (внутрикорпоративные «магазины приложений»), Integrated Platforms and Ecosystems, Actionable Analytics («аналитика, направленная на принятие быстрых решений») — этот тренд стимулировался Большими Данными, и такой тренд как «Windows 8» или «Microsoft на мобильных платформах».
Мне представляется, что здесь нет дословного перевода, и нужно применять т.н. «художественный». Например, как вариант, можно предложить: «Анализ сложности алгоритмов: базовый курс», или «Анализ сложности алгоритмов: основные понятия», или «Анализ сложности алгоритмов: введение для начинающих».
Чтобы дополнительно показать, что статья рассчитана на читателя, не сильно осведомленного в этой теме, можно поставить галочку «учебный материал» при публикации поста.
Да, пост изначально был помечен как «tutorial», и поэтому содержит предельно упрощенные примеры. Мы пытаемся писать различный по уровню контент, — например, см. наш предыдущий пост по теме бэкапа и отказоустойчивости сервисов высокой доступности: "Архитектура BigData-инфраструктуры сервиса Pandorama и защита ее данных от сбоев"
По процитированному примеру — согласен с замечанием о его неясности — у меня оказалось пропущено описание «исходной ситуации». Речь шла о случае, когда в продуктивном сервере установлен один диск, и его отказ влечет необходимость восстановления данных из резервной копии. Backup-сервер — это управляющий сервер продукта резервного копирования. На нем тоже один диск. Речь шла о случае, когда происходит одновременный сбой этих двух дисков — в результате чего продукт резервного копирования не может функционировать и процесс восстановления продуктивной системы будет зависеть от времени восстановления Backup-сервера. Конечно, в реальной системе, скорее всего будет установлен RAID массив (и/или применены другие методы обеспечения отказоустойчивости), и проблема будет носить менее выраженный характер.
И, в целом, вы очень хорошо сформулировали основную мысль этого примера — я бы только добавил, что еще идея была в том, чтобы показать, что бэкап-инфраструктура должна рассматриваться как часть продуктивной инфраструктуры, так как от нее, в определенных случаях, зависит RTO при восстановлении продуктивной системы.
Процесс восстановления в Pixar был подробно описан Oren Jacob в его комментарии к этому же ролику (что приведен выше), на этом ресурсе. См. по ссылке самый верхний комментарий. " I'm the Oren Jacob in the video. Hopefully I can offer some first person color commentary about the video above that might serve to answer the questions here.". Ролик же просто не стали перегружать деталями.
В частности, там есть такой момент: "With Galyn's machine now back in the building, we dupe'd that data immediately, then set about the task of trying to verify and validate this tree, which we thought might be about 2 weeks old. We compared Galyn's restoral with a much older one (from 2 months prior) and couldn't determine a clear winner, there were too many inconsistencies. So, instead, we set about the task of assembling what effectively amounted to a new source tree, by hand, one file at a time. The total number of files involved was well into the six figures, but we'll round down to 100,000 for the sake of the rest of this discussion to make the math easier."
В целом согласен во всем: по сути нужно ставить цель, имеющую реальную значимость для компании/проекта (например, релиз продукта c некоторым функционалом <опущу сейчас вопросы точной формулировки>), и поставить ее для команды в целом. Когда у людей есть общая цель, они начинают сотрудничать, в результате чего получается синергетический эффект от объединения людей в группу. Тем не менее, без индивидуальной оценки работы (упомянутые в статье «ранги» или их аналоги) вряд ли получиться обойтись, но оценивать нужно именно по вкладу в достижение общей цели с поправкой на должность и опыт участника команды. По сути нужно подобрать правильное для конкретной компании сочетание общих и индивидуальных целей.
Есть опасность, что со временем про такой метод набора узнают «охотники за бонусами», которых заинтересует сделать задачу и отправить ее решение от имени разных людей и хорошо на этом заработать, при этом у них нет цели трудоустройства.
Странно, что в опросе не было, на мой взгляд, более важных для «оборудования офиса» пунктов, например: «хорошее освещение», «удобное функциональное кресло», «эргономичная клавиатура», «комфортная нешумная обстановка» (openspace vs. кабинеты,- о чем уже в комментариях написали выше) и т.д.
ОК, может, я ответил, немного неверно поняв ваш изначальный вопрос: итак, на вопрос «зачем нужна вторая локальная копия?», могу дать такой ответ: «для отказоустойчивости и уменьшения RTO и RPO (так как процесс восстановления В/ИЗ удаленного хранилища обычно не быстрый)». Если в этом нет большой необходимости, то, конечно, согласен с вами,- вторая локальная копия данных не нужна.
Еще могло быть терминологическая неточность. Первой копией данных я называю сами оригинальные данные, второй локальной их копией — первую резервную локальную копию.
Полагаю, вы имеете в виду ситуацию, когда дифференциальный бэкап делается (как он описан в классике), скажем, 6 дней в неделю, а на 7 день проходит полный бэкап (назовем это схемой «6+1»). В этом случае мы имеем историю изменения данных за неделю (фактически 7 исторических копий данных), и, конечно, такой способ намного надежнее, чем случай с тремя копиями. Однако, если администратор не заметит заражения файла за неделю, или если дифференциальный бэкап делается не по описанной схеме 6+1, а скажем, 3+1, или 2+1, то и этот способ может не помочь избежать потери оригинальной (не зараженной вирусом) копии файла.
В статье я хотел описать некий минимальный уровень количества резервных копий. Хотел показать, что две — точно мало. По сути, описана следующая концепция: когда у вас есть постоянно меняющиеся оригинальные данные, нужно как можно чаще делать их дубликат (реплику, вторую копию) на другом физическом носителе. Чем чаще будете снимать дубликат данных, тем лучше будет RPO (то есть будет меньше потерянных новых изменившихся данных в случае, если произойдет сбой оригинального диска). Т.о. хранилище «второй копии» д.б. быстрым — то есть лучше всего на эту роль подходит дисковое СХД. Вторым аргументом в пользу быстрого дискового СХД является RTO (скорость восстановления после сбоя). Но у такого подхода есть и «обратная сторона».
Минусом такого подхода по организации «максимально быстрого регулярного создания второй копии», является тот факт, что все искаженные или испорченные данные, будут точно также очень быстро продублированы. Т.о. «вторая копия» — это по сути не средство резервного копирования, а средство обеспечения лишь отказоустойчивости.
По сути, только третья копия (и последующие) является средством резервного копирования, если она создается уже по другому, более «медленному», расписанию (скажем, не мгновенно, а раз в день), а сохранение идет в другую среду, чем диски (то есть, например, в облако или на ленты). Эта третья копия (и последующие) хранят по сути историю изменений за период времени, чем их больше -конечно тем лучше. Тем больше у администратора возможностей заметить заражение файла и откатится к той версии файла, когда он был еще не заражен.
Да, я имел в виду, что, когда мы имеем совокупность (в смысле «группу объектов»), скажем, из двух зеркалируемых копий данных, расположенных на двух одинаковых по характеристикам дисках, то вероятность сбоя отдельного диска в целой группе будет больше, чем в случае единственного диска, просто за счет того, что объектов больше. При этом надежность такой группы выше, чем у единственного диска, потому что сбой отдельного диска в такой зеркалированной группе не является критическим событием (ведь копия данных осталась на втором диске), а вероятность одновременного сбоя всех дисков в группе — меньше пропорционально степенной функции (то есть квадрату, кубу и т.д. вероятностей сбоя отдельных дисков).
Говоря проще: когда у вас два автомобиля, а не один, то вы среднестатистически за год в два раза чаще посещаете сервис (то с одной, то с другой машиной), при этом вероятность остаться вообще без средства передвижения в некий день у вас квадратично ниже, чем в случае одного автомобиля. (Иными словами за надежность группы машин выше)
Лучше всего такой вопрос задать на портале техподдержки, так как могут потребоваться логи и информация об окружении, а такой информацией лучше обмениваться в частном порядке.
Или, можно задать этот вопрос на форуме Veeam Backup,- там тоже оперативно отвечают.
К сожалению, планов по поддержке Citrix нет. Несмотря на то, что Citrix делает очень хорошие продукты, и, по мнению Gartner, на момент июня 2012 года, Citrix является лидером в области серверной виртуализации на базе архитектуры x86, но, увы, его рыночная доля слишком мала, чтобы (в настоящий момент) сделать целесообразной разработку полномасштабного бэкап-продукта под него. Данные о рыночных долях расходятся, но достаточно точно можно утверждать, что на долю Microsoft и VMware приходится более 85%-90% рынка. Например, на эту тему можно посмотреть статью: "Рынок серверной виртуализации выбирает платные гипервизоры"
C сегодняшнего дня доступны бесплатные NFR ключи для Veeam Backup Cloud Edition:
1) Cloud Edition of Veeam Backup & Replication 6.5 for Hyper-V для Microsoft Certified Professional, Microsoft Certified Technology Specialist и Most Valuable Professional — Free NFR for Backup Cloud Edition for Hyper-V
2) Cloud Edition of Veeam Backup & Replication 6.5 для VMware vExpert, VMware Certified Professional и VMware Certified Instructor — Free NFR for Backup Cloud Edition
Реализованных проектов в России еще нет, так как продукт только выпущен. Я согласен, что в России компании не склонны доверять «внешним провайдерам», но для них мы и предоставляем возможность шифрования резервных копий, помещаемых в облако. В тоже время на рынках США и Западной Европы, особенно в сегменте малого и среднего бизнеса (SMB), использование облаков становится все более актуальным. Дело в том, что, например, Amazon за последние 5 лет снизил услугу по стоимости хранения в 25 раз! И небольшие компании, когда принимают решение (1) купить себе собственный лишний СХД для внеофисного хранения резервных копий или купить себе ленточный накопитель (2) или использовать сравнительно дешевое облачное хранилище, которое не нужно обслуживать собственным ИТ-персоналом (которого у нее обычно толком то и нет), начинают все больше заинтересовываться вторым вариантом. Более того, по мнению Gartner, в течение следующих 5 лет SMB-компании на западе ДОЛЖНЫ начать выбирать второй вариант, чтобы сохранить конкурентоспособность (по их мнению, этот вариант будет дешевле и оптимальнее). Причины, насколько я могу судить, в том, что собственная железка (1) требует ИТ персонала, который в ней разбирается — за него надо платить (2) обладает фиксированным диапазоном емкости дисков (сначала компания переплачивает за неиспользованное дисковое пространство, а потом его начинает ей не хватать). Облако же позволяет небольшим компаниям не думать о планировании собственного хранилища и расходов на него.
Я читал, что Microsoft объясняет это тем, что «с точки зрения пользовательских сценариев, не характерно применение USB устройств на сервере». Поэтому они и отложили эту фичу в «долгий ящик». Пользователи уже приводили им в ответ, что, например, некоторый серверный софт может иметь защиту от нелицензионного копирования, основанную на USB ключах и т.п.
О некоторых способах решения этой проблемы можно посмотреть, например, в посте Rick Vanover здесь
Чтобы дополнительно показать, что статья рассчитана на читателя, не сильно осведомленного в этой теме, можно поставить галочку «учебный материал» при публикации поста.
По процитированному примеру — согласен с замечанием о его неясности — у меня оказалось пропущено описание «исходной ситуации». Речь шла о случае, когда в продуктивном сервере установлен один диск, и его отказ влечет необходимость восстановления данных из резервной копии. Backup-сервер — это управляющий сервер продукта резервного копирования. На нем тоже один диск. Речь шла о случае, когда происходит одновременный сбой этих двух дисков — в результате чего продукт резервного копирования не может функционировать и процесс восстановления продуктивной системы будет зависеть от времени восстановления Backup-сервера. Конечно, в реальной системе, скорее всего будет установлен RAID массив (и/или применены другие методы обеспечения отказоустойчивости), и проблема будет носить менее выраженный характер.
И, в целом, вы очень хорошо сформулировали основную мысль этого примера — я бы только добавил, что еще идея была в том, чтобы показать, что бэкап-инфраструктура должна рассматриваться как часть продуктивной инфраструктуры, так как от нее, в определенных случаях, зависит RTO при восстановлении продуктивной системы.
В частности, там есть такой момент: "With Galyn's machine now back in the building, we dupe'd that data immediately, then set about the task of trying to verify and validate this tree, which we thought might be about 2 weeks old. We compared Galyn's restoral with a much older one (from 2 months prior) and couldn't determine a clear winner, there were too many inconsistencies. So, instead, we set about the task of assembling what effectively amounted to a new source tree, by hand, one file at a time. The total number of files involved was well into the six figures, but we'll round down to 100,000 for the sake of the rest of this discussion to make the math easier."
Еще могло быть терминологическая неточность. Первой копией данных я называю сами оригинальные данные, второй локальной их копией — первую резервную локальную копию.
В статье я хотел описать некий минимальный уровень количества резервных копий. Хотел показать, что две — точно мало. По сути, описана следующая концепция: когда у вас есть постоянно меняющиеся оригинальные данные, нужно как можно чаще делать их дубликат (реплику, вторую копию) на другом физическом носителе. Чем чаще будете снимать дубликат данных, тем лучше будет RPO (то есть будет меньше потерянных новых изменившихся данных в случае, если произойдет сбой оригинального диска). Т.о. хранилище «второй копии» д.б. быстрым — то есть лучше всего на эту роль подходит дисковое СХД. Вторым аргументом в пользу быстрого дискового СХД является RTO (скорость восстановления после сбоя). Но у такого подхода есть и «обратная сторона».
Минусом такого подхода по организации «максимально быстрого регулярного создания второй копии», является тот факт, что все искаженные или испорченные данные, будут точно также очень быстро продублированы. Т.о. «вторая копия» — это по сути не средство резервного копирования, а средство обеспечения лишь отказоустойчивости.
По сути, только третья копия (и последующие) является средством резервного копирования, если она создается уже по другому, более «медленному», расписанию (скажем, не мгновенно, а раз в день), а сохранение идет в другую среду, чем диски (то есть, например, в облако или на ленты). Эта третья копия (и последующие) хранят по сути историю изменений за период времени, чем их больше -конечно тем лучше. Тем больше у администратора возможностей заметить заражение файла и откатится к той версии файла, когда он был еще не заражен.
Говоря проще: когда у вас два автомобиля, а не один, то вы среднестатистически за год в два раза чаще посещаете сервис (то с одной, то с другой машиной), при этом вероятность остаться вообще без средства передвижения в некий день у вас квадратично ниже, чем в случае одного автомобиля. (Иными словами за надежность группы машин выше)
Нашел небольшую статью на эту тему (англ. яз.): "RAID1 increases chances of disk failure".
Или, можно задать этот вопрос на форуме Veeam Backup,- там тоже оперативно отвечают.
1) Cloud Edition of Veeam Backup & Replication 6.5 for Hyper-V для Microsoft Certified Professional, Microsoft Certified Technology Specialist и Most Valuable Professional — Free NFR for Backup Cloud Edition for Hyper-V
2) Cloud Edition of Veeam Backup & Replication 6.5 для VMware vExpert, VMware Certified Professional и VMware Certified Instructor — Free NFR for Backup Cloud Edition
О некоторых способах решения этой проблемы можно посмотреть, например, в посте Rick Vanover здесь