CDP — ПРОЕКТ УГЛЕРОДНОЙ ОТЧЕТНОСТИ
Услуги по верификации углеродной отчётности
Проект углеродной отчетности (The Carbon Disclosure Project — CDP), существующий с 2000 г., стал золотым стандартом методологии и процесса раскрытия информации по выбросам парниковых газов. Он является важнейшим источником данных в области климатических изменений для мирового рынка. Электронная база данных по углеродной отчетности CDP является крупнейшим в мире регистром, содержащим наиболее полную информацию по корпоративным выбросам парниковых газов (GHG) и корпоративным стратегиям в области изменения климата.
Большое количество организаций во всех экономически развитых странах проводят оценку выбросов парниковых газов, результаты которой публикуются вместе с описанием корпоративной стратегии в области изменения климата.
Независимая верификация отчетов CDP в самой ближайшей перспективе должна стать неотъемлемой частью глобальной системы корпоративной углеродной отчетности, обеспечивающей уверенность пользователей в достоверности данных, оказывающих влияние на процесс принятия инвестиционных решений.
Что такое верификация углеродных выбросов?
Верификация углеродных выбросов в Бюро Веритас — это процесс независимого анализа информации по результативности и управлению, на основе которого формируется заключение, обеспечивающее уверенность предполагаемых пользователей данной информации в том, что она представлена достоверно и аккуратно.
Какие основные преимущества проведения верификации углеродных выбросов?
Выполнение требований по верификации опросного листа CDP для наиболее полного раскрытия результативности, что, в свою очередь, обеспечивает:
– включение компании в Индекс Лидеров Углеродной Отчетности (Carbon Disclosure Leaders Index — CDLI);
– включение компании в Индекс Лидеров Углеродной Результативности (Carbon Performance Leaders Index — CPLI);
Обеспечение достоверной и надежной информации в соответствии с основными целями раскрытия информации (CDP, корпоративная отчетность, сертификация и др.);
Повышение эффективности внутреннего углеродного учета и системы внутренней отчетности;
Создание надежной основы для оценки энергопотребления и выработки стратегий сокращения выбросов;
Создание потенциала для интеграции верификации углеродной отчетности с другими сертификационными услугами.
ПОЧЕМУ БЮРО ВЕРИТАС?
Действуя как независимый орган, аккредитованный Рамочной Конвенцией по Изменению Климата ООН (UNFCCC), Бюро Веритас является лидером на рынке верификационных услуг в Беларуси и странах СНГ, а также одним из лидеров по валидации и верификации углеродных выбросов в рамках Европейской Схемы Торговли Эмиссиями (European Union Emissions Trading Scheme — EU ETS), Механизма Чистого Развития, реализации Проектов Совместного Осуществления и национальных схем торговли выбросами. Мы также осуществляем верификацию и сертификацию по стандартам ISO14064, PAS2050, GHG Protocol, Global Reporting Initiative G3, The Carbon Trust Standard и др.
Глобальное представительство в более чем 140 странах и эффективное взаимодействие между офисами обеспечивает нашим заказчикам преимущества от использования наилучшего опыта международного сотрудничества, наряду с глубоким пониманием национальных требований.
Наши заказчики имеют преимущество благодаря широкому охвату всех секторов производства и глубокому знанию отраслевой специфики, вместе с полным пониманием требований к управлению углеродными выбросами на международном, национальном и локальном уровне.
Как Углеродная Отчетность может повлиять на принятие инвестиционного решения?
Публикация добровольной углеродной отчетности, верифицированной независимым международным аккредитованным органом, позволяет компании продемонстрировать всем заинтересованным лицам результативность контроля выбросов и мероприятий по их сокращению. Эта информация может оказать существенное влияние на принятие инвестиционных решений в отношении компаний – крупных эмитентов парниковых газов, так как демонстрирует защищенность компании от рисков (в том числе и финансовых), связанных с действиями правительства и международного сообщества по предотвращению угрозы изменения климата и контролю выбросов парниковых газов. К таким действиям можно отнести введение квот на выбросы парниковых газов, реализация внутренней схемы торговли выбросами, требования по раскрытию информации об эмиссиях со стороны международных финансовых институтов и т.д.
Какой подход использует Бюро Веритас для верификации Углеродной отчетности?
Для разработки экспертного заключения на углеродную отчетность в рамках CDP мы используем опыт проведения верификации углеродной отчетности и сокращения выбросов в данном секторе. Основным содержанием верификации является проверка соответствующих количественных данных и анализ качественных заявлений в соответствии с установленными применимыми критериями. Результатом верификации является независимое экспертное заключение, в котором указывается область верификации, подход, и профессиональное аудиторское заключение, подтверждающее корректность данных и аккуратность расчетов. Выводы аудита могут быть использованы организацией для улучшения организации сбора данных и разработки отчетности.
Сколько стоит работа по верификации заявления по выбросам парниковых газов?
Стоимость работ определяется исходя из области производственной деятельности предприятия, объема заявления по парниковым газам, количества источников выбросов/поглотителей, выбранного уровня неопределенности, а также от включения косвенных энергетических выбросов.
Cdp report что это
CDP is a not-for-profit charity that runs the global disclosure system for investors, companies, cities, states and regions to manage their environmental impacts. Over the past 20 years we have created a system that has resulted in unparalleled engagement on environmental issues worldwide. Find out more about how we work.
CDP Scores
CDP Cities data story
Our research shows cities, states and regions are at the forefront of climate action.
Disclosure in 2021 and beyond
Our latest information on disclosure timelines for 2021
Our vision is for a thriving economy that works for people and planet in the long term. Together, we can tip the balance and achieve this vision.
For a list of all our upcoming events please visit our events page.
CDP is a global organization, with regional offices and local partners spanning 50 countries. There are now companies, cities, states and regions from over 90 countries that disclose to CDP.
United Kingdom
USA and Canada
Press contact
Anna Clark
Telephone: +1 646-668-4184
anna.clark@cdp.net
CDP Europe
Policy and public affairs:
cory.fletcher@cdp.net
Cities, states and regions
etienne.metais@cdp.net
Japan
Michiyo Morisawa
Director, Japan
Telephone: +81 (0)3 6225 2232
japan@cdp.net
Latin America
Rebeca Lima
Executive Director, Latin America
Telephone: +55(11)23056996
reportecdpla@cdp.net
Australia and New Zealand
Hong Kong and South East Asia
China
Sabrina Zhang
Director, China
Telephone: +86-10 8341 2867
sabrina.zhang@cdp.net
India
Damandeep Singh
Director, India
Telephone: +91 98100 45950
damandeep.singh@cdp.net
«> 
Veeam CDP для самых маленьких
Вот об этом мы сегодня и поговорим: что это за магия такая, как она работает и как мы её реализовали в Veeam Backup & Replication v11.
Зачем CDP нужен этому миру
Начинаем по порядку: а какие проблемы может решить CDP и кому он нужен?
CDP удобнее всего сравнивать с асинхронной репликацией стораджей. То есть ваши виртуалочки спокойно работают, а где-то там далеко внизу одно хранилище реплицирует данные на другое, как бы гарантируя вам, что в случае сбоя вы потеряете минимум информации и просто продолжите работать в новом месте.
Так что если снапшоты можно исключить, их надо исключить.
Как работает CDP
Хотелось бы так, но нет. На практике всё несколько сложнее. Давайте разбираться.
Вот так выглядит общая схема работы. Для видавшего виды VBR пользователя здесь знакомо только слово Proxy. И, пожалуй, да, на прокси вся схожесть с классическими схемами работы и заканчивается.
Координатор. Умывальников начальник и мочалок командир. Управляет всеми процессами, отвечает за связь с vCenter, говорит другим компонентам, что делать, и всячески следит, чтобы всё было хорошо. На местах выглядит как Windows сервис. Единственный, кто знает про существование таких вещей, как vCenter и виртуальные машины. Все остальные работают только с дисками. Поэтому всё, что не связано с репликацией контента, делает координатор. Например, создаёт виртуалку на таргете, к которой мы прицепим реплицируемые диски.
Source filter. Та самая штука, которая занимается перехватом IO запросов. Соответственно, работает уже на ESXi. Дабы повысить надёжность и производительность, один инстанс фильтра работает с одним виртуальным диском. Фильтры держат связь с демоном.
Зачем нужна прокладка в виде демона и почему бы фильтру самому не работать с прокси? Это ограничение технологии со стороны VMware, не позволяющее фильтру работать с внешней сетью. То есть фильтр с демоном связь установить может, а с прокси нет. Это называется by design, и ничего с этим не поделаешь. Во всяком случае, сейчас. И напомню: демон не знает ни про какие виртуальные машины. Он работает с потоками данных от дисков. И ничего другого в его мире не существует. Поэтому диски одной машины могут обрабатываться сразу несколькими прокси. Мы, конечно, стараемся отвозить диски одной машины через один прокси, но если она не справляется, то подключится другая. И это нормально!
Source Proxy. Агрегирует в себе всю информацию, полученную от фильтров через демонов. Хранит всё строго в RAM, с возможностью подключения дискового кэша, если оперативка кончилась. По этому очень (ОЧЕНЬ!) требователен к RAM, дисковому кешу и задержкам на сети. Так что только SSD и прочее адекватное железо.
Прокси занимается составлением так называемых микроснапшотов, которые отправляются дальше. Данные перед передачей обязательно дедуплицируются: если в каком-то секторе произошло 100500 перезаписей, то до прокси дойдут все, но с самого прокси будет отправлена только одна последняя. Так же, само собой, всё сжимается и шифруется. На местах прокси представляют собой Windows машины, которые могут взаимозаменять друг друга, переключать нагрузку и так далее.
Target Proxy. Всё то же самое, но в обратном порядке. Принимает трафик от сорсных проксей, расшифровывает, разжимает, отправляет дальше. Так же может быть как физический, так и виртуальный.
Target Daemon. Занимается записью данных на датастор. Полная копия сорсного демона.
Target Filter. В нормальном состоянии находится в выключенном виде. Начинает работать только во время фейловера и фейлбека, но об этом позже.
Таргетные компоненты от сорсных в данном случае отличаются только названием и своим местом в логической схеме. Технически они абсолютно идентичны и могут меняться ролями на ходу. И даже одновременно работать в двух режимах, чтобы одна машина реплицировалась с хоста, а другая на хост. Но я вам ничего такого не говорил и делать не советовал. Также в момент переключения реплики в фейлбек таргеты переключаются на роль сорсов, а в логах появится соответствующая запись.
Немного промежуточных деталей
Сейчас хочется немного отвлечься на разные детали, понимание которых даст нам более полную картину в будущем.
Как мы видим, процессы, связанные с CDP, довольно плотно интегрированы в сам хост. Так что при выполнении многих операций надо быть предельно внимательным. Например, апгрейд/удаление VAIO драйвера происходит строго через maintenance mode. Установка, что хорошо, такого не требует. На случай отсутствия DRS предусмотрена защита, которая не даст запуститься процессу, однако это же IT, и бывает тут всякое. Поэтому действовать надо осторожно и внимательно.
И ловите бонус: фильтр с хоста можно удалить командой:
И дальше по обстановке.
И, конечно же, не забудем обрадовать ненавистников разного рода устанавливаемых на гостевую ОС агентов и сервисов. Для CDP ничего такого делать не надо, и даже админские креды никому больше не нужны (если только вы готовы отказаться от VSS точек с application consistent состоянием). Наконец-то угнетатели повержены и можно спать спокойно. Всё работает исключительно за счёт магии VAIO API.
Retention
На длинной дистанции мы используем Long-term retention, гарантирующий консистентность на уровне приложений(application aware). Делается это с помощью VSS и требует предоставления админской учётки от гостевой ОС. Выглядит это как создание точек отката с определённой периодичностью (например, раз в 12 часов), которые хранятся несколько дней.
Расписание, само собой, гибко настраивается, позволяя, например, обеспечивать crash-consistent только в офисное время, а в ночное переключаться на редкие, но application-consistent точки.
Если подходить глобально, то вариантов сделать фейловер у нас два: прямо сейчас по кнопке Failover now… или создав Failover Plan. Соответственно, если случилась авария, то мы можем сделать фейловер нашей реплики в следующих режимах:
Откат на последнее состояние (crash-consistent)
Восстановиться на нужный нам момент времени в режиме Point-in-time (crash-consistent)
Откатиться на Long term точку (здесь можно выбрать между application-aware и crash-consistent)
А failback и permanent failover делаются по правилам обычных старомодных реплик, так что останавливаться на этом не буду. Всё есть в документации.
Совет: в выборе нужного момента времени при Point-in-time ресторе очень удобно двигать ползунок стрелочками на клавиатуре 😉
Как работает CDP ретеншн
И прежде чем мы начнём обсуждать, почему вы поставили хранить три точки отката, а на диске их двадцать восемь, давайте посмотрим, что вообще будет храниться на таргетной датасторе.
.VMDK Тут без сюрпризов. Обычный диск вашей машины, который создаётся в момент первого запуска репликации.
Short-term retention
Теперь рассмотрим, как это работает.
В первый момент времени на таргете нет ничего, поэтому, чтобы начать работать, нам надо взять и в лоб поблочно скопировать VMDK файл с сорса на таргет.
Совет: если тащить по сети огромный VMDK вам нет никакого удовольствия, то Seeding и Mapping вам в помощь. Они позволяют перевести ваши файлы на таргетный хост хоть на флешке в кармане, в дальнейшем подключив их к заданию.
Возникает закономерный вопрос: каков размер этих самых блоков? Он динамический и зависит от размера диска. Для простоты можно считать, что 1 Тб диска соответствует 1 Мб блока.
Как только VMDK перевезён, можно начинать создавать дельта диски. Для чего фильтр и демон начинают отслеживать IO машины, отправляя по сети всё, что пишется на машине.
Этот поток сознания, приходя на сорс прокси, проходит через процедуру отбрасывания лишних блоков. То есть если некий блок за период репликации был перезаписан несколько раз, то в дельту уйдёт исключительно последнее его состояние, а не вообще все. Это позволяет сохранять вагон ресурсов и два вагона пропускной способности вашей сети.
Рядом с дельта диском создаётся транзакцонный лог.
Если лог становится слишком большим, то создаётся новый дельта диск.
И так всё работает до достижения выбранного Retention policy. После чего Veeam смотрит на содержимое лога.
Если это просто устаревшая точка восстановления, которая нам больше не нужна, то данные из неё вносятся в наш базовый диск, и файлы удаляются.
Если оказывается, что в логе нет вообще ничего, необходимого для создания новых точек восстановления, такой файл сразу удаляется.
Примечание: Соблюдение Retention Policy довольно важно. Однако поддержка CDP реплики в боевом состоянии ещё важнее. Поэтому в механизм заложена потенциальная возможность временного расширения периода хранения до 125% от первоначального.
Long-term retention
Служит логическим продолжением short-term retention. То есть всё работает ровно так, как и написано выше, пока не наступает момент создать long-term точку.
В этот момент создаётся особый дельта диск. Внешне он не отличается от других, однако во внутренней логике он помечается как long-term delta.
Репликация продолжает идти своим чередом.
Когда подходит время для срабатывания short term, то все предыдущие логи и дельта диски (если их несколько) просто удаляются.
Теперь всё считается от этой long-term точки. Она остаётся нетронутой и высится как глыба.
Затем создаётся новая long-term точка, и цикл замыкается.
Когда подходит время, то самая первая long-term точка инжектируется в базовый VMDK.
Про логику транзакций
Путь данных с оригинальной машины до реплицированной можно разбить на два логических участка, водораздел которых проходит по source proxy.
Отсюда два важных следствия:
Если мы не успеваем передать данные на участке фильтр-демон-прокси, они считаются безвозвратно потерянными, и сделать с этим уже ничего нельзя.
На втором участке задержка уже не критична. Если даже в какой-то момент времени мы не успеваем получить подтверждение от таргетного демона, то данные остаются в кеше сорсного и таргетного прокси и будут переданы ещё раз. Если кажется, что такое кеширование избыточно, то это кажется. Сети сейчас, конечно, быстрые, но зачем лишний раз лезть далеко, если можно попросить данные ближе? В логе джобы в этот момент возникнет предупреждение, что RPO нарушено, но ничего критичного ещё не случилось. Позднее данные будут довезены до таргета.
Что под капотом у фильтров
Теперь, когда мы разобрались на базовом уровне в устройстве и принципах работы CDP, давайте посмотрим более внимательно на работу отдельных компонентов. А именно фильтров. Ведь именно от их красивой работы зависит всё остальное. И как мы все прекрасно понимаем, ровно и красиво может быть только в лабораторных условиях. Именно там у нас всегда стабильный поток IO операций, нет резких всплесков нагрузки, сетевые пакеты никуда не пропадают, и все графики выглядят как прямая рельса, уходящая за горизонт.
Вот так вот можно изобразить на любимых всеми квадратиках с буквами режимы работы. В данном примере у нас установлено RPO 10 секунд, из которых пять секунд (половина RPO) мы отслеживаем изменения данных, а вторую половину времени пытаемся передать последнее их состояние. То есть, промежуточные, как я говорил выше, нас не интересуют.
А вот что случается, когда мы не получаем подтверждение доставки от таргета. Данные мы собрали, однако передать их не можем. В этот момент Veeam начинает сохранять в сторонку номера таких блоков. И только номера, никаких данных. Почему? Потому что когда связь восстановится, нам надо передать актуальное состояние блоков.
Примечание: Чтобы администратор спал спокойней, предусмотрены два оповещения, скрывающихся под кнопкой RPO Reporting. Фактически они просто считают, сколько данных за указанный промежуток времени мы можем потерять. И бьют в набат, если что-то пошло не так.
Инфраструктура
Обычно, когда заходит речь о проработке какой-либо инфраструктуры, все сразу начинают думать про CPU и RAM. Но только не в этот раз! Здесь надо начинать с поиска вашего сетевика, чтобы он сделал вам сеть с наикратчайшим маршрутом, с 10 Gbit+ линками, и не забыл включить MTU 9000 (Release Jumbo frames. ) на всём протяжении маршрута. Согласно нашим тестам, такой набор нехитрых действий позволяет добиться прироста производительности почти на 25%. Неплохо, да?
И общий совет на все случаи жизни: десять маленьких CDP политик всегда будут работать лучше и стабильней, чем одна большая. Что такое маленькая политика? Это до 50 машин или 200 дисков. В мире большого энтерпрайза это считается за немного. Технически, опять же, здесь ограничений нет, и проводились успешные тесты аж до 1500 машин и 5000 дисков. Так что лучше, опять же, протестировать на месте и найти оптимальный для себя вариант.
Немного о прокси
И хотя кажется, что прокси серверам в схеме CDP отведена роль тупых молотильщиков трафика, без их успешного взаимодействия всё остальное теряет смысл. И задачи там решаются достаточно серьёзные, так что не будем принижать их вклад в общее дело.
Что хочется сказать про этих ребят:
Не надо заставлять один и тот же прокси сервер выступать в роли сорсного и таргетного. Ничего хорошего из этого не выйдет. Запретить вам так сделать мы не можем, однако будем долго отговаривать.
Да и вообще, общая логика такова, что чем больше вы сможете развернуть прокси серверов, тем лучше будет результат. Особенно если речь идёт о репликации между удалёнными дата центрами.
Также самые внимательные заметят, что на шаге назначения проксей есть кнопка Test с таинственным набором цифр внутри.
Давайте разбираться что же это такое и откуда оно взялось. Все эти скорости и количества являются ничем иным, как усреднёнными максимумами за последний час, полученными от vCenter. То есть это не мы что-то там померили в моменте, ловко запустив какие-то таинственные тесты, а такова родная статистика хостов за последний час.
Давайте теперь пройдёмся по строчкам.
Source Proxy CPU: количество ядер CPU на всех доступных проксях, которые могут работать в качестве сорса. Видим vCPU, но читаем как ядра CPU.
Source Proxy RAM. Здесь уже посложней будет. Цифра перед скобками показывает, сколько оперативки нам может понадобиться для данной CDP политики.
Формула расчёта довольно простая: RPO* пропускную способность.
Пропускную способность кого/чего? Да всех дисков всех вируталок, участвующих в этой политике. Напоминаю, что берётся максимальное значение за последний час.
Source Proxy Bandwidth. Здесь опять всё просто. Число перед скобками мы получаем от vCenter, а число в скобках считается на основе доступного количества ядер с округлением до целого. Если мы шифруем трафик, то это 150 Мб/с на ядро. Если не шифруем, то 200 Мб/с на ядро.
Target Proxy CPU. Всё ровно так же, как у сорса: взяли и посчитали все доступные ядра на доступных проксях.
Target Proxy RAM. Хочется, как и в предыдущем пункте, сказать, что всё такое же, но нет. Здесь в формулу для расчёта внесён поправочный коэффициент 0.5. А значит, что если мы за те же 15 секунд хотим обработать 150 Мб/c от дисков, то понадобится нам уже только 1125 RAM (вместо 2250, как это было с сорсом).
И помним важное: таргет и прокси меняются ролями в момент фейловера. То есть вся схема начинает работать в обратную сторону. Поэтому на таргете и есть неактивный фильтр, который оживает в момент фейловера. А фильтр на бывшем сорсе, соответственно, выключается.
Быстрое Ч.А.В.О. в конце
Как добавить в CDP Policy выключенную машину?
Никак. Виртуалка выключена > фильтр не работает > передавать нечего.
Какие версии vSphere поддерживаются?
Хочу минимальное RPO, чтобы ну вообще ничего не потерялось.
Если у вас железо хорошее (прям хорошее-хорошее, а не вам кажется, что хорошее), то вполне реально добиться RPO в 2 секунды. А так, в среднем по больнице, вполне реально обеспечивать 10-15 секунд.
А что с vRDM?
Всё отлично поддерживается.
А можно CDP прокси назначить и другие роли?
Назначайте, мы не против. Только следите за соответствием доступных ресурсов предполагаемым нагрузкам.
А можно CDP реплику, как и обычную, использовать для создания бекапов?
Нет. Во всяком случае сейчас.
Я могу запустить CDP реплику из консоли vCenter?
Нет. С точки зрения vCenter там какой-то фарш из дельта дисков, поэтому он выдаст ошибку зависимостей.
А если я руками удалю CDP реплику из Inventory в vCenter?
Умрут все id и всё сломается. А вы чего ожидали?
А если таргетная стора будет чем-то очень загружена?
Veeam будет присылать на почту уведомления, что очень старается, но у вас ботлнек на принимающей стороне и нельзя впихнуть невпихуемое.
А что с Hyper-V?
Это вопрос к Microsoft.
Немного полезных ESXi команд
Убить daemon сервис:
Остановить/запустить daemon сервис:
Полюбопытствовать насчет последних логов демона:
Выяснить, сколько памяти потребили все демоны:
Проверить установку пакета фильтра. Он выглядит как обычный vib
