Милі та пухнасті

Блог

  • Как можно отслеживать свои группы Office 365?

    У администраторов есть два способа с помощью встроенных инструментов выяснить, какие существуют группы Office 365 и кто в них входит. К сожалению, в обоих случаях требуется значительный объем ручной работы, и оба способа нс отличаются хорошими возможностями масштабирования.

    Просмотр вручную через порталы администрирования

    Самый простой способ просмотреть группы Office 365 и их участников — использовать портал администриро­вания Office 365 или центр администрирования Exchange. Отличить в списке гостей обычно не составляет труда по внешним адресам электронной почты.

    Если в вашей компании 100 рабочих мест и вы недавно перешли на Office 365, то ручная проверка групп может быть приемлемым решением, по крайней мере временно. Но для более крупных или давно использующих Office 365 компаний, количество групп в которых может исчисляться десятками тысяч, такой подход неприемлем.

    PowerShell

    Для перечисления всех групп и их участников можно воспользоваться командами PowerShell. Вы можете даже подготовить сценарии, чтобы, например, определить все группы с внешними участниками. Но и в этом случае вы сталкиваетесь с необходимостью регулярно просма­тривать огромные массивы данных вручную. Поэтому часто предпочтительно приобрести сторонние инструменты, которые упрощают процесс просмотра групп и членства в них.

    Если вам нужна помощь в переносе информации в облако, мы профессионально проведем ее. Обращайтесь!

  • Следует ли беспокоиться о разрастании групп Office 365?

    Разрастание групп — огромная проблема в современной локальной среде. Если общедоступные папки и группы Exchange не подвергаются строгому контролю, то постепенно накапливаются большие объемы данных. Хранить, архивировать и управлять ими очень затратно, особенно если необходимо сохранять высокую доступность. Однако в «облаке» подписка Office 365 по умолчанию предоставляется с большим пространством для хранения данных. Почему проблема разрастания групп актуальна в «облаке», если с ней не связано никаких неизбежных затрат?

    Дело в том, что фиксированная стоимость —лишь часть общей стоимости разрастания групп, как локально, так и в «облаке». В локальной среде фиксированные затраты настолько велики, что по сравнению с ними другие затраты часто ничтожны. Однако при переходе в «облако» увеличивается значимость других затрат, связанных с разрастанием, особенно относящихся к удобству использования и безопасности. Оценить эти затраты труднее, чем расходы на хранение данных, но от этого проблема не становится менее актуальной.

    Прежде всего, наличие большого числа групп приводит к путанице и потере производительности. Глобальный список адресов, который постоянно используется всеми сотрудниками, может вырасти до нескольких тысяч записей, что затруднит поиск получателей, без которого невозможно эффективно работать с электронной почтой.

    А затем проблемы групп и членства в них. нарастают как снежный ком: пользователям трудно выяснить, существует ли уже группа для данных целей, поэтому создаются дублирующие группы и появляются многочисленные группы с разными владельцами, предназначенные для похожих целей. В результате разрастание групп мешает решить задачу, ради которой были созданы группы Office 365, — улучшить обмен данными и совместную работу.

    Еще более важно, что разрастание групп повышает угрозу безопасности из-за потери возможностей учета. Владельцы увольняются из компании, и их группы оказываются потерянными. Аттестация трудна, поэтому даже группы с добросовестными владельцами часто имеют участников, у которых более нет рабочей необ­ходимости в доступе к ресурсам. Это нарушает принцип предоставления минимальных прав, обязательный для обеспечения безопасности.

    Кроме того, можно упустить из виду группы, включающие гостей, и данные оказываются открытыми для внешнего доступа. Через группы также открывается доступ к конфиденциальным и под­надзорным данным, поэтому обеспечить соответствие требованиям очень трудно.

    Если вам нужна помощь в переносе информации в облако, мы профессионально проведем ее. Обращайтесь!

  • Существует ли способ выполнить аттестацию групп Office 365?

    Важно регулярно выполнять аттестацию групп Office 365, чтобы убедиться, что группа по-прежнему необходима. Термин «аттестация» относится к повторной проверке (обычно владельцами и участниками групп), в ходе которой выясняется, у всех ли участников и гостей по-прежнему есть потребность состоять в группе и обращаться к ресурсам и рабочим нагрузкам.

    Как отмечалось выше, с каждой группой Office 365 связаны корпоратив­ные данные и службы, поэтому регулярные аттестации необходимы для защиты, обеспечения соответствия требованиям, предотвращения потери и нарушения целостности данных. К сожалению, встроенного механизма, обеспечивающего сквозную аттестацию, нс существует.

    Вместо этого компании должны подготовить сценарии PowerShell, чтобы составить список участников каждой группы и разработать особое решение для обработки выходных данных PowerShell с последующей отправкой их по электрон ной почте владельцам групп для аттестации.

    Для решения этой проблемы в предварительной версии предусмотрена еще одна функция — проверки доступа Azure AD. В каждой группе можно заставить каждого пользователя повторно сертифицировать собственный доступ или поручить одному или нескольким пользова­телям проверить доступ для всех остальных.

    Если вам нужна помощь в переносе информации в облако, мы профессионально проведем ее. Обращайтесь!

  • Как стандартизировать именование групп Office 365?

    Компаниям полезно иметь возможность контролировать именование групп. В частности, удачные, согласован­ные имена групп позволят сотрудникам легко найти группу в глобальном списке адресов и понять, для чего она предназначена.

    Однако стандартов для именования групп Office 365 на сегодня не существует; пользователь, создавший группу, может дать ей любое имя. Компаниям приходится по-прежнему именовать группы так же, как они делали это до появления групп Office 365 — устанавливая стандарты, публикуя их и обучая пользователей. При этом в общедоступной предварительной версии Office 365 есть функция политики именования. С помощью этой политики можно сделать следующее.

    • Запретить использование определенных слов в имени группы. Вы можете определить набор слов, которые нельзя использовать в именах групп, в частности оскорбительные слова или такие, которые могут привлечь внимание злоумышленников, например «директор» или «платежная ведомость».
    • Добавлять префикс или суффикс к именам групп. Префикс и суффикс можно добавлять к имени группы автомати­чески. Вы можете указать фиксированную строку или ввести атрибут пользователя, например «|Department!», и соответствующее значение вводится в зависимости от связанного атрибута пользователя, создавшего группу.

    Эта функция должна в некоторой степени помочь в применении стандартов именования, хотя по-прежнему потребуется обучение пользователей. Но заданную возможность придется платить: вам потребуются лицензии Azure AD Premium Pl для всех пользователей, имеющих членство в группах Office 365 на клиенте.

    Если вам нужна помощь в переносе информации в облако, мы профессионально проведем ее. Обращайтесь!

  • Могу ли я добавить кого-нибудь не из моей компании в свою группу Office 365?

    Возможно, вы захотите добавить в свою группу Office 365 партнеров, поставщиков, консультантов или других участников не из вашей компании. Вы можете пригласить этих людей стать «гостями» в группе. Участники могут представлять гостей, но только владельцы групп могут добавлять их в группу.

    Чтобы добавить гостя, владелец группы просто указывает адрес электронной почты соответствующего пользовате­ля в диалоговом окне Add member («Добавить участника») в Outlook. Гость получит приветственное письмо с информацией о группе и способах участия. В зависимости оттого, как была создана группа, возможно, потребуется выполнить некоторые действия, чтобы позволить гостям связываться с группой по электронной почте.

    Все взаимодействия гостя с группой производятся через его ящик электронной почты; он не может обращаться к сайту группы напрямую. Если гость участвует в группе через приложение Office 365, такое как Teams, то он будет использовать функциональность этого приложения. Гости могут получать календарные приглашения, участвовать в диалогах по электронной почте и открывать общие файлы с помощью ссылки или вложения (если администратор клиента нс отключил эту функцию).

    Подробную информацию о том, что именно могут делать гости, можно найти в статье Guest access in office 365 groups базы знаний Microsoft (https://support.office.com/). Все электронные сообщения и календарные приглашения группы будут содержать ссылку, с помощью которой гости могут покинуть группу, и, конечно, владелец группы может удалять гостей.

    Мы окажем профессиональную помощь при переезде в облако. Свяжитесь с нами!

  • Могут ли пользователи управлять принадлежащими им группами Office 365?

    Да. Базовые функции управления группами предус­мотрены в приложениях, используемых для создания групп. В Outlook владельцы могут добавлять и удалять участников и гостей, изменять имя группы и параметры безопасности и т. д. Приложения, которые создают и используют группы скрыто, такие как Teams, предо­ставляют очень похожую функциональность.

    Обратите внимание, что способа удалять отдельные функции управления не существует. Например, нельзя лишить владельца группы возможности изменить имя группы. Кроме того, у каждой группы может быть до 100 владельцев, все с одинаковыми полными правами управления. Встроенных возможностей делегировать функции управления определенной группой также нс предусмотрено.

    Если вам нужна помощь в переносе информации в облако, мы профессионально проведем ее. Обращайтесь!

  • Концепция гибкой интеграции

    Концепция гибкой интеграции

    Успех современного бизне­са чем дальше, тем боль­ше зависит от способности реагировать на изменения. Новые игроки нарушают баланс на рынке, а технологии в корне меняют ожидания потреби­телей, и компаниям приходится кор­ректировать свои планы. Благодаря современным программным архи­тектурам и процессам компании могут лучше приспосабливаться к переменам и побеждать в конку­рентной борьбе.

    В новой архитектурной инфраструк­туре. именуемой гибкой интеграцией, соединены три важных архитектурных компонента: контейнеры, распреде­ленная интеграция и программные интерфейсы (API). Данная инфра­структура определяет, как перечис­ленные ключевые компоненты обе­спечивают гибкость и эффективность новых процессов, происходящих вну­три компании, принося ей конкурент­ные преимущества.

    В таких отраслях, как, например, туризм и гостиничное дело, произош­ли важные перемены — предоставля­ются новые возможности, а потреби­тели иначе взаимодействуют с поставщиками услуг. Глубокие изменения охватывают и другие крупные отрасли, от финансового сектора до госучреж­дений. Их подстегивают разрабаты­ваемые технологии и новый взгляд на взаимодействие между компаниями и потребителем. Приспосабливаясь к вызовам современного мира, ком­паниям приходится радикально пере­страивать свои ИТ-технологии, чтобы предложить новые услуги.

    Для доставки программного обеспече­ния на современных скоростях компа­ниям нужен фундамент гибкой инфра­структуры. В данном случае в термин Agile вкладывается более традицион­ный смысл, чем обычно при разработ­ке программ. Agile означает «гибкий», «способный быстро двигаться».До настоящего времени гибкие мето­дики были направлены на разработку программного обеспечения в стремле­нии усовершенствовать и упростить процесс создания программ. Методы DevOps представляли собой попытку перенести эти методики на разверты­вание приложений.

    Однако область действия методоло­гии DevOps ограничена и охватывает в основном новые приложения, само­стоятельно разрабатываемые компа­ниями. Гибкость инфраструктуры распро­страняется дальше и создает среду, которая охватывает все ИТ-системы, в том числе устаревшие программы. Гибкая инфраструктура — подход, который нивелирует сложность суще­ствующих систем, различных типов данных, потоков данных и позволяет объединить их. В этом суть проблемы интеграции.

    Компания, которая может в одно­часье изменить цепы или быстро начать выпускать новые продукты, имеет огромное преимущество перед конкурентом, использующим трехмесячную многоэтапную процедуру с последовательностью ручных опе­раций проверки.Мы называем это гибкой интеграци­ей. Интеграция не является частью инфраструктуры — это концептуальный подход к инфаструктуре, который охватывает данные и приложения наряду с оборудованием и платформами. Совмещая техно­логии интеграции с гибкостью и тех­нологиям и DevOps, можно создать платформу, которая позволяет рабо­чим группам вносить изменения так быстро, ка к того требует рынок.

    Конец планирования

    «Планирования, каким мы его знаем, больше не существует, — заявил в своем выступлении на конферен­ции Red Hat Summit Джим Уайтхерст, главный управляющий Red Hat.— Планирование в малоизученной среде неэффективно». В стремительно развивающейся бизнес-срсде неспо­собность лавировать, своевременно корректируя свои действия, может обойтись чрезвычайно дорого. Это означает, что чем меньше информа­ции вы имеете или чем менее стабиль­на среда, тем ниже ценность планов.

    Планирование инфраструктуры обычно требует долгосрочного под­хода. Попытка составить многолет­ний план порой подавляет способ­ность к реагированию на резкую смену ситуации на рынке . Конец планирования, о котором говорил Джим Уайтхерст, означает возмож­ность планировать быстрее, а затем воплощать свои планы. Сокращается время существования планов и самой среды, в которой реализуются новые проекты .

    Рабочим группам, привычным к полу­годовым или даже двухлетним циклам разработки, непросто приспособить­ся к быстрым переменам. Проблема усугубляется, когда традиционно структурированные компании бывают вынуждены конкурировать с начи­нающим и компаниями , которые используют совершенно новые под­ходы. Очевидные примеры — N etflix и Blockbuster или Uber и традицион­ное такси, но подрыв устоявшегося порядка молодыми компаниям и прослеживается с начала информа­ционного века, с Amazon в 1993 году и персональных компьютеров в 1980-х (таблица 1).

    Преимущество начинающих компа­ний в свободе выбирать свою инфра­структуру, организовы вать рабочие группы , приложения, архитектуру и даже процессы развертывания.
    У них не только есть новаторская идея — они могут реализовывать свои замыслы, поскольку их не сдержива­ет устаревшая инфраструктура. Они могут быть гибкими.

    Помимо возможности построить что-то новое, такие компании соз­дают системы, готовые к переменам. Почти любой компонент системы у них может быть обновлен или заме­нен в зависимости от меняющихся потребностей рынка. По мере того как возраст стартапов увеличивается, способность к адаптации некоторых из них падает, но лучшие компании всеми силами стараются не потерять способности адаптироваться к пере­менам.

    Что необходимо для успеха

    Для эффективной работы в быстро меняющейся среде вся ИТ -инфраструктура должна функционировать гибко. Изменения могут происходить на двух уровнях:

    • организационная и культурная поддержка гибких процессов — от проектирования архитектуры до связи между рабочими группа­ми;
    • техническая инфраструктура , которая позволяет быстро обновлять, добавлять и удалять функ­циональные возможности.

    Технические и культурные измене­ния не обеспечивают гибкость. О ни создают фундамент для гибкости. Марти Каган , менеджер продукта компании eBay, облагает каждый проект « налогом » — некоторое время и ресурсы из каждого обыч­ного проекта выделяются для работы над новыми инфраструктурным и проектам и. Таким образом, новые проекты и новации становятся при­оритетными.

    Инфраструктура гибкости

    Многочисленные новые технологии часто не способствуют созданию гибкой инфраструктуры , поскольку различные группы двигаются в раз­ных направлениях, исследуя возможности для совершенствования. Без согласованного набора целей верхне­го уровня трудно определить, какой набор новых функциональных воз­можностей принесет наибольшие выгоды для компании в целом.

    Три столпа гибкой интеграции

    Подход к гибкой интеграции базиру­ется на трех основных технологиях:

    • Распределенная интеграция. Нес­колько десятков высокоуровневых шаблонов интеграции отражают потоки данных и рабочих процессов на предприятии. Если эти шаблоны интеграции развернуты в контейне­рах, то их можно развернуть в нуж­ных масштабах и там, где необхо­димо для конкретных приложений и рабочих групп. Это архитектура распределенной интеграции, отличная от традиционной архитектуры централизованной интеграции. Благодаря ей отдельные рабочие группы могут гибко определять и развертывать требуемые шабло­ны интеграции.
    • API-интерфейсы. Стабильные, хоро­шо управляемые A P I-интерфейсы имеют решающее значение для взаимодействия между рабочи­ми группам и, разработчиками и специалистами по эксплуата­ции. A P I-интерфейсы заключают важнейшие активы в стабильные, повторно используемые интерфей­сы, позволяя этим интерфейсам служить строительными блоками для многократного применения в масштабах компании, с партне­рами и клиентами. API-интерфейсы можно размешать вместе с контей­нерами в различных средах, что позволяет пользователям взаимо­действовать с разными наборами API-интерфейсов.
    • Контейнеры. Это базовая платфор­ма развертывания как для API, так и для технологий распределенной интеграции. Контейнеры позво­ляют развернуть нужную службу в определенной среде простым и единообразным для разработ­ки, тестирования и обслуживания способом. Поскольку контейне­ры являются доминирующей платформой для среди микро ­служб DcvOps, их использование в качестве платформы интеграции обеспечивает более прозрачное и тесное сотрудничество между группами разработчиков и специ­алистами по инфраструктуре.

    Благодаря трем перечисленны м технологиям И Т-инф раструктура становится более гибкой, посколь­ку каждая из них повышает уровень абстракции, на котором различные рабочие группы могут действовать совместно. Использование контейнер­ной платформы с АРІ-интерфейсами и распределенными интеграционными компонентами абстрагирует реализа­цию интеграции от самой интеграции.

    Гибкость рабочих групп повышается, так как API-интерфейсы и шаблоны распределенной интеграции упаковы­вают конкретные активы на понятном уровне и при этом нет необходимости изменять базовую инфраструктуру. Каждая из названных технологий в отдельности обеспечивает зна­чительную гибкость при решении конкретных задач интеграции. При совместном использовании они обеспечивают мультипликативный эффект. Преимущества технологии увеличиваются в сочетании с мето­диками DcvOps, особенно процесса­ми автоматизации и развертывания.

    Распределенная интеграция

    Одна из крупнейших проблем совре­менных ИТ-систем состоит в необ­ходимости объединять приложе­ния в масштабах всей компании. Трудности интеграции приводят к созданию все более сложных центров интеграции. Эти центры, часто реали­зуемые как корпоративные сервисные шины (ESB), превратились в чрезвы­чайно сложные узкие места, не поддающиеся быстрым изменениям.

    Распределенная интеграция позво­ляет достичь во многом тех же техни­ческих целей, что и предшествующие поколения ESB, но способом, более удобным для адаптации рабочими группам и. Как и ESB, технология распределенной интеграции обе­спечивает преобразование, марш­рутизацию, анализ, обработку оши­бок и рассылку предупреждений.
    Различие заключается в архитектуре интеграции.

    В архитектуре распределенной инте­грации каждая точка интеграции рас­сматривается как отдельное и уни­кальное развертывание, а нс часть более крупного, централизованно­го приложения интеграции. Затем интеграцию можно поместить в кон­тейнер и развертывать локально для конкретного проекта или рабочей группы, не влияя на другие интеграции, развернутые в компании.

    Распределенный подход обеспечи­вает необходимую гибкость проек­тов. В нем используется та же цепочка инструментов, которая применяется рабочими группами DevOps, благода­ря базовой контейнерной платформе, что увеличивает способность рабо­чих групп управлять своими инте­грациями с помощью собственных инструментов и расписания. В сущности, интеграция рассматривается как микрослужба, что ускоряет про­цессы разработки и выпуска.

    Критическое значение имеет согла­сование процессов и инструментов разработчика. Главная особенность распределенной интеграции состо­ит в том, что это не централизованная программная инфраструктура, разработанная и управляемая спе­циализированной группой поль­зователей водном подразделении и развернутая отдельно от процесса разработки программного обеспе­чения. Благодаря распределенности архитектуры интеграции, с обшей платформой и инструментарием, она доступна всем разработчикам на уровне проекта и поддерживает компактные развертывания всегда и везде, где необходима интеграция.

    Чтобы использовать ESB, рабочей группе приходится в течение всего жизненного цикла применять инструменты ESB наряду с любы­ми инструментами, используемыми в средах разработки и эксплуатации (таблица 2).

    Результатом становятся неудобство, потери в эффективности и ошибки при эксплуатации.

    Обмен сообщениями способствует интеграции

    Архитектурно точки интеграции при распределенной интеграции рас­сматриваются как микрослужбы. Их можно заключать в контейнеры, легко развертывать локально и часто обновлять выпуски. Технология интеграции должна под­держивать такого рода компактную архитектуру на основе микрослужб. С помощью, например. Red Hat Fuse пользователи могут рассматривать интеграции как программный код, пригодны й для запуска повсюду, втом числе в контейнере.

    Кроме того, Fuse поставляется с Red Hat J Boss A M Q , чтобы обеспечить инфраструктуру обмена сообщения­ми. Мощная инфраструктура обмена сообщениями гарантирует эффек­тивную марш рутизацию событий и данных между системами. Обмен сообщения ми — важный архитектур­ный инструмент для микрослужб, поскольку его асинхронная природа не требует зависимостей.

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

    Следим за тенденциями

    Контейнеры применяются все чаще, но насколько и почему? Аналитики компании 451 Research прогнозиру­ют рост рынка на 250%, но это объем затрачиваемых средств, а не развертывания. Оценить развертывания несколько сложнее. В результате опроса, выполненного компанией Bain по заказу Red Hat. выяснилось, что около 20% клиентов сегодня развертывают контейнеры в производ­ственной среде и примерно столько же в средах разработки и тестирования, но более 30% оценивают контейнеры и выполняют проверку концепции.

    Что означает «использовать контей­неры»? В Enterprisers Project обрисованы четыре различных варианта применения контейнеров: в каче­стве общей платформы разработки и развертывания; ка к «облачной» платформы или платформы микро­служб; в гибридном «облаке» и для инновационных проектов. От спосо­ба использования контейнеров зави­сит, как пользователь рассматривает их внедрение.

    Идея гибкой интеграции заключа­ется в создании инфраструктурной платформы, поддерживающей суще­ствующие операции. На платформе могут быть представлены все вариан­ты реализации, но в своей основе она работает как фундамент для новых проектов и существующих служб.

    Источник: журнал “Windows IT Pro/RE”

  • Репликация в «облако» Microsoft Azure с использованием QoreStore

    Репликация в «облако» Microsoft Azure с использованием QoreStore

    Quest QoreStor — это программно определяемая платформа дополнительного хранилища данных, используемая для ускорения резервного копирования, сокращения стоимости и требований к хранилищу данных, а также осуществления более быстрой и надежной «облачной» репликации. Используя такого поставщика «облачных» услуг, как Microsoft Azure, для архивации и аварийного восстановления, вы получаете все преимущества простоты, безопасности и избыточ­ности выбранной «облачной» платформы.

    В данной статье речь пойдет о том, как реплицировать локальные резервные копии из QoreStor в «облако» Microsoft Azure. Настройка репликации — простой процесс, занимающий очень немного времени после того, как вы настроите источник и целевой объект.

    Как известно, репликация — процесс копирования резервных копий в другое место; это ключевой элемент многих стратегий аварийного восстановления. Репликация QoreStor позволяет защитить серверы, рабочие станции и данные, сохраняя актуальные копии в допол­нительном расположении (локальном, удаленном или в «облаке»), зашифрованном с использованием 256-разрядного алгоритма AES.

    «Облачная» репликация

    «Облачная» репликация — один из важнейших новых компонентов современного подхода к защите данных. Обладатели QoreStor могут использовать стороннего поставщика услуг, такого как Microsoft Azure, чтобы управлять удаленной средой QoreStor ка к услугой. Иногда ее называют «аварийное восстанов­ление ка к услуга» (DRaaS).

    В «облачной» репликации исполь­зуются как «облачные» службы, так и «облачные» хранилища. «Облачные» хранилища избавляют от необходимо­сти приобретать и обслуживать доро­гостоящие локальные хранилища для архивации и аварийного восстановле­ния, особенно в условиях быстрого роста данных.

    Благодаря «облачной» репликации вы можете меньше беспокоиться об инфраструктуре и сосредоточить­ся на задачах бизнеса, одновременно выполняя все требования по защите данных и аварийному восстановле­нию . Среди дополнительных пре­имуществ «облачной» репликации можно назвать следующие:

    • Масштабируемость. «Облачное» хранилище объектов практически не ограничено по емкости при минимальных дополнительных затратах. Для расширения хра­нилища необходимо обратиться к поставщику «облачного» хранилища или самостоятельно подготовить пространство с использовани­ем веб-портала самообслуживания поставщика. Конечно, при расширении хранилища затраты обычно увеличиваются.
    • Гибкие соглашения об уровне обслужи­вания (SLA). «Облачное» хранилище можно организовать с различными соглашениями SLA, чтобы удовлет­ворить всевозможные требования к хранению данных. Например, одни «облачные» решения ориен­тированы на долгосрочное хранение с редкими обращениями к данным (АКА-архивирование), а другие про­ектировались для более неотложных нужд (аварийное восстановление). Обычно «облачное» хранилище имеет встроенную избыточность, обеспечивающую дополнительный уровень зашиты данных.
    • Аварийное восстановление. «Облачная» репликация позволяет воспользоваться преимуществам и высокой надежности и доступности «облачного» хранилища, чтобы добиться соответствия стандартам непрерывности бизнес-процессов нс выходя за рамки бюджета.

    Репликация QoreStor

    QoreStor хранит резервные копии от выбранного вами поставщика, сжи­мая, шифруя и выполняя дедуплика­цию данных. Таким образом при хранении данных достигается экономия в соотношении до 20:1. После развер­тывания QoreStor обеспечивает управ­ляемую и плановую асинхронную репликацию, требующую по крайней мере двух экземпляров QoreStor, сое­диненных через локальную или гло­бальную сеть, где оба сервера можно адресовать по ІР-адресу или FQDN .

    В частности, контроль репликации осуществляется через управляемую репликацию из программы резервного копирования или через интерфейс репликации в QoreStor. Репликация настраивается в прямом соотношении I : I , поэтому копию можно использо­вать для аварийного восстановления или в качестве долгосрочной вспомо­гательной копии, а резервные копии старших поколений реплицируются и хранятся, пока не будут удалены в соответствии с применяемой поли­тикой.

    Исходный экземпляр репликации (расположенный в рабочем центре обработки данных) может быть раз­вернут на физическом сервере или виртуальной машине с поддержкой Нурег-V, VMware и KVM (рисунок I ).

    При развертывании в качестве физи­ческого сервера можно задействовать оборудование практически любого поставщика с поддержкой хранилища до 360 Тбайт до дедупликации. При развертывании в качестве виртуальной машины, что идеально для малых наборов данных и удаленных офисов, QoreStor поддерживает хранилищ а до 43 Тбайт до дедупликации.

    Целевой экземпляр репликации и QoreStor может выполняться внутри Microsoft Azure, а также в дру­гих «облаках», используя специали­зированный , оптимизированный для «облака» режим , встроенный в QoreStor. Он представляет собой настроенную установку QoreStor, которая поддерживает хранилище до 43 Тбайт до дедупликации и сертифицировано компанией Quest для запуска с использованием экземпляра DS2v3 со скоростью приема данных до I Тбайт/ч.

    О птимизированный для «облака» режим QoreStor пред­назначен для того, чтобы довести затраты на «облачные» вычисления до уровня менее 200 долл, в месяц. Для развертывания репликации QoreStor на Azure необходимо сначала приоб­рести соответствующий экземпляр Azure и подготовить учетную запись хранилища с достаточной пропускной способностью и вместимостью. Чтобы упростить расчет необхо­димых вычислительных ресурсов и емкости хранилищ а, компания Quest разработала калькулятор, который можно приобрести у авторизо­ванных партнеров Quest.

    QoreStor Sizing Calculator выдаст подробные требования, в том числе к вмести­мости хранилища и оборудованию, в зависимости от размера и скоро­сти приема данных, ка к показано на экране I .

    Обратитесь по адресу: https://cloud.foglight.com /app. чтобы найти подходящий экземпляр Azure и оценить доступны еэкземпля­ры Azure по регионам и ресурсам.

    Выделение дисков Azure — важней­ший шаг для обеспечения рабочих характеристик; оно зависит от вари­анта «облака» (C loud O p tim ize d , Standard или Large). Выбранный экземпляр Azure необходимо разместить как Red Hat Enterprise Linux 7.3 (или более новой версии) и подключить к нему несколько дисков Azure. Чтобы упростить управление, рекомендуется задействовать в качестве файловой системы расширяемый том LVM и XFS. Это позволит легко выделять дополнительное пространство для хранения данных.

    Таким образом, QoreStorсможет немедленно исполь­зовать хранилище без дополнительной настройки продукта. После запуска экземпляра Azure можно установить и настроить QoreStor, как показано на экране 2.

    Помимо развертывания QoreStor в режиме Cloud Optimized с пятью дискам и Azure, альтернативные режимы QoreStor требуют допол­нительной настройки, чтобы обеспечить требуемую пропускную способность подключенного хранилища.

    Для запуска QoreStor с подключен­ным хранилищем свыше 43 Тбайг специалисты Quest рекомендуют подготовить выделенный SSD-диск для операционной системы и другой SSD-диск для метаданных QoreStor.

    Предпочтительно использовать SSD для метаданных, чтобы операции чтения и записи в словарь не оказы­вали негативного влияния на произ­водительность. Для хранения данных требуется несколько дисков в кон­фигурации линейно чередующегося LVM.

    На экране 3 показана установка Quest QoreStor в Azure с хранилищем на 50 Тбайт и накопителем SSD емко­стью 1 Тбайт для метаданных. Инструкции по настройке Linux с LVM можно найти в руководстве Urban Penguin, Striped LVM Volumes . Рекомендации по настройке производительности диска содержатся в статье базы знаний Microsoft Azure Premium Storage: Design for High Performance. В процессе работы для QoreStor потребуется по крайней мере одна группа хранения, настроенная для « контейнеризации» данных.

    Группы хранения QoreStor позволяют применять отдельные политики для сжатия и дедупликации к разным наборам данных или на крупных предприятиях, к данным различ­ных подразделений. MSP используют группы хранения для управления различными клиентами (экран 4).

    Следует отметить, что никакие две группы хранения не могут задейство­вать один ключ шифрования, тем самым обеспечивая безопасность и разделение данных.

    Репликация шаг за шагом

    Настройка QoreStor для репликации в Azure или любой другой локальный, удаленный или «облачный» сайт — простой процесс, занимающий очень мало времени после того, как выбра­ны исходный и целевой экземпляры QoreStor (экран 5).

    Ниже приводится подробное описание шагов настройки репликации контейнера хранилища QoreStor С IFS/NFS.

    Репликация для контейнеров хра­нилища CIFS и NFS настраивается непосредственно из пользователь­ского интерфейса QoreStor. Чтобы настроить репликацию для контей­нера протокола Rapid Data Access (RDA) или контейнера OST, управ­ление политикой репликации осу­ществляется через программы Quest NclVault Backup или Veritas Net Backup and BackupExec соответственно.  В перечисленных ниже шагах указаны требования для репликации CIFSh NFS.

    Первый шаг настройки реплика­ции — перейти к панели реплика­ции и нажать кнопку Add Replication («Добавить репликацию»), как пока­зано на экране 6.


    Второй шаг — выбрать репликацию локальных или удаленных контейне­ров. В примере на экране 7 исполь­зуется локальный вариант.


    Третий шаг — настроить шифрование для потоков данных (экран 8).


    Последний шаг — выбрать целевой экзем пляр в Azure, предоставить учетные данные и выбрать контей­нер хранилища назначения (экран 9).


    После завершения настройки репли­кации всеми параметрами всех задач репликации можно управ­лять из панели QoreStor Replication Dashboard, как показано на экране 10.


    Редактирование задач репликации включает те же шаги, что и начальная настройка, и позволяет пользовате­лям изменять шифрование и кон­тейнеры хранилищ а назначения (экран 11).

    После настройки QoreStor начнет репликацию из исходных экземпляров в целевые. С помощью QoreStor в Azure пользо­ватели смогут быстро и эффективно настроить репликацию вне офиса, мгновенно создавая избыточность и сокращая риск для аварийного вос­становления без затрат на оборудо­вание и долгосрочных обязательств.

    После запуска оба экземпляра QoreStor могут быть подключены к QoreStor GlobalView, чтобы задействовать пор­тал «облачного» управления и подготовки отчетов. Подключение происходит в два этапа. Первый шаг выполняется из GlobalView, где формируется маркер проверки подлинности (экран 12),

    а второй — из панели QoreStor Management Dashboard (экран 13).


    GlobalView отображает предупрежде­ния, диагностические данные, экономию пространства для хранения данных и общее состояние всех под­ключенных экземпляров QoreStor.
    Кроме того, G lobalView содержит интерфейсное окно Proxy, которое обеспечивает полное управление каким-либо доступным и подключен­ным экземпляром QoreStor с любого подключенного к Интернету устройства, как показано на экране 14.

    Прямое резервное копирование в «облако»

    В дополнение к реплицированию резервных копий в «облако» для ава­рийного восстановления. QoreStor может использоваться как первичное
    целевое хранилище для резервного копирования в «облако» напрямую.

    С помощью подключаемых модулей QoreStor Rapid Plugins данные деду­плицируются в источнике резервной копии, а затем отправляются зашиф­рованными в QoreStor в «облаке», как показано на рисунке 2.

    Если связь посети между источником и QoreStor исчезает или нестабильна, функ­ция QoreStor SecureConnect будет постоянно предпринимать попытки завершить резервное копирование и пересылку данных. Это обеспечи­вает завершение резервного копиро­вания и защиту данных.

    Источник: журнал “Windows IT Pro/RE”

  • Реализация непрерывной доставки обновлений

    Реализация непрерывной доставки обновлений

    Организация бесперебойной доставки обновлений для конечного пользователя – это крайне важный процесс, который должен учитываться в разработке с самого начала. Но что если нужно создать непрерывный поток для сторонней платформы? Попытаемся разобраться на явном примере.

    Онлайн-система клиента была создана на основе Kubernetes, размещенной на собственных мощностях. Затем, все это перекочевало на платформу заказчика, что потребовало организации непрерывной доставки. Польза от этого решения очевидна – оперативное и комфортное обновление, не затрагивающее клиентов.

    Разделим организацию Continuous Deployment (CD) на несколько этапов:

    1. Старт процесса
    2. Синхронизация со сторонним Git
    3. Бэкэнд и фронтэнд
    4. Тестовая среда и развертывание пробной версии
    5. Автоматическое развертывание в рабочей среде

    1. Старт процесса непрерывной доставки обновлений

    CD процесс всегда берет начало с «выкатывания» новой версии продукта в Git-репозитории.

    Отметим, что созданное ПО для клиента имеет архитектуру на базе микросервисов, в котором есть лишь один единственный репозиторий для всех компонентов. Почему выбран именно этот метод? Вот несколько преимуществ:

    • Свежее ПО всегда нуждается в доработке или добавлении новых возможностей, а значит, придется иметь дело с целым кодом.
    • Это помогает организовать правильный CD, с помощью которого не игнорируется ни один компонент.
    • Отпадает необходимость создания карты версий, так как обновляется абсолютно все.

    2. Синхронизация со сторонним Git

    Имеется в виду, синхронизация с репозиторием клиента, когда все обновления автоматически выкатываются на удаленную платформу. Как только в ветке появляется новая версия, начинается процесс сборки тестовой, а затем и рабочей версий.

    Нужно учитывать тот факт, что клиентский репозиторий недоступен для прямого воздействия, потому что инструменты, среды разработки и другие платформы отличаются. А значит, синхронизация репозиториев – лучшее решение. Любое изменение на нашем сервере переносится на клиентский.

    3. Бэкэнд и фронтэнд

    На данном этапе работа должна вестись параллельно, так как они должны учитываться в системе GitLab Runner.

    GitLab Runner берет из репозитория нужный для процесса код, чтобы потом собрать приложение на Java и отправить его в Docker. Именно здесь и будет происходить процесс организации бэкэнда и фронтэнда. Результатом будет готовый Docker-образ, в дальнейшем отправляемый на стороннюю платформу. Чтобы управлять образами нам пригодится специальный плагин Gradle.

    Не забываем про синхронизацию в Docker! Не лишними будут следующие настройки:

    1. Очень удобно, если контейнер сможет работать со всеми данными как в тестовой, так и в «боевой» версиях.

    2. Чтобы реализовать процесс обновления на Helm, придется указывать версии. Всего их три: от бэкэнда, фронтэнда и самого обновления. Единый Git-репозиторий упрощает задачу.

    Чтобы получить данные о текущей версии, введите следующую команду:
    git describe –tags –abbrev=7

    4. Тестовая среда и развертывание пробной версии

    Далее мы выполняем тестовое развёртывание с помощью соответствующего скрипта на кластере K8S. Естественно, данный этап проходит лишь после успешной сборки и публикации в Docker Registry.

    Сначала обновляется окружение, а сам кластер получает данные за счет Helm Update. Это удобный инструмент, который автоматически вернет все «как и было», если развертывание не удалось. Параллельно с основными данными для обновлений, на кластер приходит отдельный пакет с обновленной конфигурацией. Учитывается абсолютно каждый компонент.

    Затем, Helm использует процедуру RollOut для массового обновления работающего ПО. Все действия и этапы реализуются исключительно в пределах тестовой среды. Только потом мы переходим к рабочей среде.

    5. Автоматическое развертывание в рабочей среде

    На самом деле, данный этап является чуть ли не самым простым, так как вся работа и тестовые процедуры уже подошли к концу. Нажимаем на нужную кнопку в GitLab и приложение обновляется полностью в рабочей среде.

    В нашем примере мы используем внешние переменные, которые берутся для обновления продукта. А вот все остальные элементы одни и те же, и используются как для тестовой версии, так и для рабочей.

    Стоит учитывать и то, что каждое приложение уникально и работает в собственной среде. А значит, нужно подходить к параметризации настроек достаточно гибко. Мы реализовали все через K8S конфигурации, а также индивидуальные настройки самой Helm.

    В нашем примере наиболее сложным этапом реализации был именно вышеописанный процесс с параметризацией, так как приходилось учитывать все до мелочей в разных средах. Плюс ко всему, мы упрощали для себя жизни, используя внешние переменные.

    Также учтите, что заданные переменные для окружения берутся из контейнеров с помощью K8S configmap. По сути, это готовый шаблон, который можно настроить на свое усмотрение. Вот простой пример реализации переменной окружения для домена:

    APP_EXTERNAL_DOMAIN: {{ (pluck .Values.global.env .Values.app.properties.app_external_domain | first) }}

    Немного поясним:

    • .Values.global.env – переменная для хранения названия
    • .Values.app.properties.app_external_domain – переменная для хранения домена, данные о котором берутся из файла .Values.yaml

    В результате, Helm может реализовать создание нужных элементов, используя configmap.yaml, в котором вы зададите определенные шаблоны. Переменная APP_EXTERNAL_DOMAIN располагается в контейнере, а ее значение будет варьироваться в зависимости от окружения.

    Кстати, в последних версиях Spring Cloud внедрили поддержку K8S. Мы планируем продолжать изучать новые возможности, а в данном случае, перейдем именно на это решение.

    Итог

    В результате, мы получили непрерывный процесс обновления на сторонней платформе, который может похвастаться своим удобством. Все происходит в автоматическом режиме и не влияет на работу пользователей приложения во время тестирования. Все системы работают исправно.

    Квалифицированный DevOps инженер с опытом более 10-и лет, реализует для вашего предприятия непрерывную доставку обновлений конечному пользователю, а также решит другие задачи связанные с организацией и разработкой ПО. Обращайтесь office@itfb.com.ua

  • Управление ИТ инфраструктурой: сетевая безопасность.

    Специально для вас мы составили материал, состоящий из двух частей, который поможет вам разобраться с различными процессами администрирования серверов, а также настройки и управления ИТ-инфраструктуры с учетом нюансов сетевой безопасности.

    Казалось бы, что здесь сложного? Соединяем несколько коммутаторов второго или третьего уровня, пробрасываем VLAN, даем разрешения на передачу данных под конкретные порты, делаем отладку роутинга и WiFi/точек доступа, после чего, по желанию, добавляем возможность удаленного управления.

    По сути, это стандартные опции, с которыми сталкивается каждый начинающий админ. Поэтому трудностей здесь быть не должно. Конечно, если нужно спроектировать более-менее обширную сеть, то придется прочесть несколько курсов по этой тематике. Но опять же, ничего сверхъестественного нет.

    У нас же речь пойдет о масштабном процессе управления ИТ инфраструктурой, когда каждая мелочь связана с целым набором других деталей, которые легко упустить из виду. Ну что же, попробуем разобраться во всем сразу!

    Выбор архитектуры

    Наиболее надежным выбором для вас станет Cisco SAFE архитектура, которая протестирована многими крупными компаниями. Стоит обратить внимание именно на модели Enterprise Campus и Enterprise Internet Edge.

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

    Базовые моменты

    Начнем с общего представления дизайна инфраструктуры. Во-первых, нужно соответствовать стандартам качества, которые установлены всемирно известными организациями. Во-вторых, нужно учесть такие моменты, как стоимость реализации и уровень ее безопасности. Также немаловажны другие аспекты:

    • Возможность масштабируемости инфраструктуры
    • Легкость в настройке/отладке
    • Отзывчивость и доступность

    Обратите внимание, что инфраструктура крупного дата-центра может отлично подойти и для вашего офиса. Поэтому, стоит рассматривать возможность переноса общей концепции.

    Тем не менее, мы начнем все с нуля. Для нас критично важным элементом является уровень безопасности сети, так как ею будут пользоваться все сотрудники, а также возможные сторонние люди (клиенты/гости и т.д.). Следовательно:

    • Нужно решить вопрос защиты внутренних данных самой компании, предполагая, что угроза может исходить как от персонала, так и от сторонних участников сети. Заодно можно захватить проблему с несанкционированным доступом.
    • Нужно обеспечить защиту всех участников сети.

    Представьте себе классический треугольник, где каждая грань обозначает какой-либо параметр или условие. В нашем случае, мы должны найти баланс между этими гранями, а именно: безопасностью-комфортом-стоимостью реализации. Посмотрим, что из этого выйдет.

    Комфорт

    С точки зрения управления современной ИТ-инфраструктурой, пользователи должны быть обеспечены следующими возможностями:

    • Высокой мобильностью
    • Привычной средой для работы (ОС, приложения и т.д.)
    • Доступностью как к внутренним, так и к внешним Интернет-ресурсам (веб-приложения, облачные сервисы и т.д.)
    • Высокой скоростью без каких-либо задержек

    Высокая мобильность

    Мы говорим о том, что каждый пользователь должен иметь возможность быстро подключиться к сети из любой точки, при наличии Интернета. Для офисной сети и для мониторинга ИТ-инфраструктуры в целом это крайне важно.

    Потому что у вас появится возможность поддерживать контакт с сотрудниками (как и они смогут общаться между собой), отправлять важные письма по электронной почте и осуществлять видеоконференции. «Будь всегда на связи» – вот девиз, которому нужно соответствовать. Чтобы решить этот вопрос, нужно правильно создать сеть из Wi-Fi-точек.

    Важно!

    Вы можете спросить: «А можно ли избавиться от Ethernet и перейти полностью на WiFi?». Конечно, да. Однако, будьте готовы к некоторым нюансам. Для нормального и более правильного администрирования сети нужен Ethernet, потому что WiFi не отличается высокой надежностью и не всегда стабилен. Более того, никто не отменял настройку выделенных портов для технической службы, которая сможет корректировать некоторые моменты в случае возникновения критических сбоев.

    Не стоит забывать и про телефонию внутри офиса. Конечно, здесь тоже можно обойтись одним Wireless VoIP, без участия привычного IP. Более того, нужно предусмотреть возможность удаленного защищенного доступа по VPN. Например, когда срочно нужно что-то сделать, сотрудник сможет подключиться к своей машине и выполнить работу. Это очень удобно. Но здесь нужно обратить внимание на ограничения в скорости передачи данных через VPN трафик.

    Легкий и быстрый доступ

    Процесс управления ИТ инфраструктурой так или иначе связан с тем, насколько быстро вы сможете решить поставленную задачу. Немаловажен и вопрос удобства интерфейса, конфигурации и т. д. В лучшем случае, аутентификация должна проводиться единожды без понижения уровня защиты сети. Но здесь нужно учесть следующее:

    • Попытайтесь спроектировать сеть таким образом, чтобы не требовать повторного подключения при необходимости смены доступа с того же дата-центра к обычным внутренним ресурсам.
    • При наличии выделенных серверов, повторная аутентификация необходима.

    Доступ к внешним ресурсам

    Речь идет о подключении к Интернет-сервисам, что очень важно для работы в офисе. Нельзя игнорировать тот факт, что многим сотрудникам важно поддерживать связь с его окружением даже во время рабочих часов. В этом нет ничего плохого, да и польза от этого решения очевидна – психологически все только выигрывают. Но, безусловно, все эти процессы нужно контролировать, чтобы избежать занесения вирусов или излишней нагрузки на сеть из-за высокого трафика.

    Привычная среда

    У каждого есть свои предпочтения касательно использования приложений и сторонних сервисов, поэтому нет ничего плохого в том, чтобы настроить гостевой VLAN посредством сети Wi-Fi. Дополнительно учтите пожелания сотрудников касательно рабочей ОС.

    Конечно, вы можете и запретить пользоваться сторонними ресурсами, обрубить Интернет или настроить статические порты. Уровень безопасности при этом вырастет в разы. Но вы потеряете с точки зрения удовлетворенности персонала. Но в некоторых случаях подобная изоляция даже необходима.

    Высокая скорость работы сети

    Работа приложений и других важных элементов в офисе может существенно замедлиться, если не настроить сеть должным образом. Но здесь нужно помнить, что далеко не всегда их скорость и отзывчивость зависит от инфраструктуры. Однако, проблемы с «бутылочным горлышком» и коммутаторами первого уровня тоже могут быть. Не исключено, что вы столкнетесь с запретами файрвола, потерей трафика и многими другими вещами.

    Например, у вас есть коммутаторы с 1 Гб-портами. Вы соединяете их между собой через Ethernet канал 2 х 10 Гб, попутно настраивая шлюзы с файрволом. С одной стороны, это достаточно простое и эффективное решение. Но с другой, вы серьезно урезаете пропускную способность сети.

    Достаточно всего пары подключений к гигабитным портам, чтобы «засорить» 2-Гб связь с файрволом. В результате, получаем деградирующую инфраструктуру. Итак, с одной гранью разобрались, теперь самое время перейти к наиболее щепетильной теме – безопасности процессов управления ИТ инфраструктурой.

    Наши специалисты могут провести полный комплексный аудит ИТ инфраструктуры любого масштаба в короткие сроки. Обращайтесь за помощью по любому вопросу на office@itfb.com.ua