Резервная площадка
Резервная площадка — это место, куда организация может переместить свою работу, полностью или частично, после стихийного бедствия, такого как пожар, наводнение, террористический акт или другое разрушительное событие[1]. Она является неотъемлемой частью плана восстановления после катастрофы и, более широко, планирования обеспечения непрерывности бизнеса организации.
В случае IT резервной или альтернативной площадкой может быть другой центр обработки данных, управляемый организацией или доступный по контракту с компанией, которая специализируется на услугах аварийного восстановления. В некоторых случаях одна организация будет иметь соглашение со второй организацией об управлении совместной резервной площадкой. Кроме того, организация может иметь взаимное соглашение с другой организацией о создании резервной площадки в каждом из их центров обработки данных.
Площадки принято классифицировать по степени готовности и скорости ввода в эксплуатацию: «холодные» (подготовлен объект), «теплые» (установлено оборудование), «горячие» (загружаются оперативные данные). — с увеличением стоимости внедрения и обслуживания с повышением «температуры»[2][3].
Классификация править
Холодная площадка править
Холодная площадка представляет собой пустое рабочее пространство с основными удобствами, такими как фальшполы, кондиционеры, линии электропередач и связи и т. д. После инцидента оборудование доставляется и настраивается для возобновления работы. В оборудование холодной площадки не входят резервные копии данных и информации из исходного местоположения организации, а также уже настроенное оборудование. Отсутствие выделенного оборудования способствует минимальным начальным затратам на холодную площадку, но требует дополнительного времени после аварии, чтобы операционная деятельность компании осуществлялось с производительностью, близкой к той, что была до аварии. В некоторых случаях на холодной площадке может быть оборудование находящееся в отключённом состоянии[4]. .
Теплая площадка править
Теплая площадка- это компромисс между горячей и холодной. Такие площадки будут иметь уже установленное оборудование и связь, хотя и в меньшем масштабе[4]. На тёплой площадке могут находиться неполные или старые резервные копии, возраст которых может составлять от нескольких дней до недели. Восстановление будет отложено, до тех пор, пока ленты резервных копий доставляются на резервную площадку или устанавливается сетевое подключение и восстанавливаются данные с удаленной резервной площадки.
Горячая площадка править
Горячая площадка — это почти дубликат исходной площадки организации с полными компьютерными системами, а также с полными резервными копиями пользовательских данных[4]. Синхронизация в реальном времени между двумя сайтами может использоваться для полного зеркалирования среды данных исходного сайта с использованием каналов глобальной сети и специализированного программного обеспечения. После сбоя в работе исходной площадки горячая площадка позволяет организации переехать с минимальными потерями для нормальной работы, обеспечивая кратчайшие сроки восстановления. В идеале, горячая площадка будет запущена в течение нескольких часов. Персонал, возможно, придется переместить на горячую площадку, но возможно, что горячая площадка сможет работать с точки зрения обработки данных до того, как персонал переместится. Емкость горячей площадки может соответствовать или не соответствовать емкости исходной площадки в зависимости от требований организации. Этот тип резервной площадки является самым дорогим в эксплуатации. Горячие площадки популярны среди организаций, которые управляют процессами в реальном времени, таких как финансовые учреждения, государственные учреждения и поставщики услуг электронной коммерции.
Самая важная функция, предлагаемая горячей, заключается в том, что производственная среда (среды) работает одновременно с основным центром обработки данных. Эта синхронизация обеспечивает минимальное влияние и время простоя для бизнес-операций. В случае серьезного сбоя горячая площадка может немедленно занять место затронутой площадки. Однако такой уровень избыточности обходится недешево, и компаниям приходится проводить анализ затрат и выгод (CBA),, чтобы принять решение об использовании горячих площадок.
В настоящее время, если площадка резервного копирования не работает и не использует «упреждающий» подход к восстановлению работы, она не может считаться горячей площадкой в соответствии с требованиями к уровню зрелости организации в отношении подхода ISO 22301 (международный стандарт управления непрерывностью бизнеса).
Альтернативные площадки править
Как правило, под альтернативной площадкой понимается площадка, на которой люди и оборудование, необходимое им для работы, перемещаются на определенный период времени до тех пор, пока не будет доступна нормальная производственная среда, восстановленная или замененная.
Выбор править
Выбор типа используемой резервной площадки определяется организациями на основе анализа затрат и выгод[4]. «Горячие» объекты традиционно дороже «холодных», поскольку большая часть оборудования, в котором нуждается компания, приходится покупать, и, следовательно, для его обслуживания требуются люди, что увеличивает эксплуатационные расходы. Однако, если та же организация теряет значительную сумму дохода за каждый день бездействия, то это может стоить затрат. Еще одним преимуществом горячей площадки является то, что ее можно использовать для операций до того, как произойдет бедствие. Этот метод производственной обработки с балансировкой нагрузки может быть экономически эффективным и обеспечит пользователям безопасность минимального времени простоя во время события, затрагивающего один из центров обработки данных.
Преимущества холодной площадки — стоимость. Для эксплуатации холодного объекта требуется меньше ресурсов, потому что до стихийного бедствия не было доставлено никакого оборудования. Некоторые организации могут хранить старые версии оборудования на такой площадке. Это может быть уместно в среде фермы серверов, где во многих случаях может использоваться старое оборудование. Недостатком холодной площадки являются потенциальные затраты, которые необходимо понести, чтобы сделать её эффективной. Затраты на закупку оборудования в кратчайшие сроки могут быть выше, а бедствие может затруднить получение оборудования.
Коммерческие площадки править
Резервные площадки могут предоставляться отдельными сервисными компаниями как законченное решение[5][6]. При заключении контракта с коммерческим поставщиком услуг резервной площадки организациям следует принять к сведению положения контракта об использовании и процедуры запуска использования мощностей. Поставщики могут зарегистрировать более одной организации для данного сайта или объекта, часто в зависимости от различных уровней обслуживания. Это разумное предположение, так как маловероятно, что все организации, использующие сервис, могут нуждаться в нем одновременно, и это позволяет провайдеру предлагать услугу по доступной цене. Однако в случае крупномасштабного инцидента, затрагивающего обширную территорию, вполне вероятно, что такие коммерческие резервные объекты будут перегружены. Организация может запросить приоритетный сервис у провайдера, что, часто, подразумевает более высокую ежемесячную оплату. Коммерческую площадку также можно использовать в качестве вторичной производственной площадки с полномасштабной зеркальной средой для основного центра обработки данных. Опять же, потребуется более высокая плата, но безопасность сайта и способность организации предоставить своим пользователям непрерывный доступ к своим данным и приложениям могут оправдать такое решение.
Литература править
- Records Management Services (2004, July 15). Vital Records: How Do You Protect And Store Vital Records?
- Haag, Cummings, McCubbrey, Pinsonneult, and Donovan. (2004). Information Management Systems, For The Information Age. McGraw-Hill Ryerson.
- IT Service Continuity (2007, ITIL v3). IT Service Continuity.
- * The Three Stages of Disaster Recovery Sites by Bryce CarrollNovember 20th, 2013
Примечания править
- ↑ Baraniuk, Chris How firms move to secret offices amid Covid-19. BBC (23 марта 2020). Дата обращения: 11 мая 2022. Архивировано 11 мая 2022 года.
- ↑ Huanhuan Xiong, Frank Fowley, Claus Pahl. A Database-Specific Pattern for Multi-cloud High Availability and Disaster Recovery // Advances in Service-Oriented and Cloud Computing / Antonio Celesti, Philipp Leitner. — Cham: Springer International Publishing, 2016. — Т. 567. — С. 374–388. — ISBN 978-3-319-33312-0, 978-3-319-33313-7. — doi:10.1007/978-3-319-33313-7_29.
- ↑ P. Fallara. Disaster recovery planning // IEEE Potentials. — 2004-12. — Т. 23, вып. 5. — С. 42–44. — ISSN 1558-1772. — doi:10.1109/MP.2004.1301248. Архивировано 11 мая 2022 года.
- ↑ 1 2 3 4 Косяченко С.А., Микрин Е.А., Павельев С.В. Методы и средства создания катастрофоустойчивых территориально-распределенных систем обработки данных. — М.: Институт проблем управления им. В.А. Трапезникова РАН, 2008. — 78 с. — ISBN 5-201-15020-9.
- ↑ Shriram Rajagopalan, Brendan Cully, Ryan O'Connor, Andrew Warfield. SecondSite: disaster tolerance as a service // Proceedings of the 8th ACM SIGPLAN/SIGOPS conference on Virtual Execution Environments. — New York, NY, USA: Association for Computing Machinery, 2012-03-03. — С. 97–108. — ISBN 978-1-4503-1176-2. — doi:10.1145/2151024.2151039.
- ↑ Mohammad M. Alshammari, Ali A. Alwan, Azlin Nordin, Imad Fakhri Al-Shaikhli. Disaster recovery in single-cloud and multi-cloud environments: Issues and challenges // 2017 4th IEEE International Conference on Engineering Technologies and Applied Sciences (ICETAS). — 2017-11. — С. 1–7. — doi:10.1109/ICETAS.2017.8277868. Архивировано 12 мая 2022 года.