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

Author: admin

  • Микросервисы и безопасность, пример

    Микросервисы и безопасность, пример

    При разработке приложения на базе SonarQube и Angular возник ряд проблем с технологией Cross-Origin Resource Sharing (CORS). С помощью SonarQube выполнялся анализ исходных кодов на различных сайтах, информацию с которых собирал главный сервис приложения. С помощью CROS и дополнительных заголовков HTTP-приложение получало разрешение на доступ к выбранным ресурсам сервера в другом домене (рис.).

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

    Сама CORS реализуется как серверами, так и браузерами. Согласно стандартам W3C, пользовательские агенты обычно блокируют сетевые запросы, исходящие из «чужих» доменов. Эти ограничения не позволяют клиентскому веб-приложению, работающему в одном домене, получать данные из другого, а также ограничивают ненадежные HTTP-запросы к доменам, отличающимся от того, в котором работает приложение.

    С учетом этого риск безопасности, связанный с CORS, был ограничен путем настройки браузеров.

  • Переход на микросервисы

    При осуществлении проектов миграции на микросервисы следует придерживаться ряда практических рекомендаций.

    Будьте готовы к организационным изменениям. Микросервисы потребуют перехода на новую корпоративную культуру.

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

    Формализуйте архитектуру(инструменты, фреймворки и т. д.). Не откладывайте выбор платформы и по возможности предусмотрите необходимые механизмы поддержки DevOps, причем чем раньше, тем лучше.

    Определите приоритетность миграции компонентов. Разработайте критерии переноса, изучите риски каждого подхода к преобразованиям, прежде чем окончательно утвердить и начать процесс.

    Разделите проект на этапы проектирования, написания кода, тестирования и интеграции. Освойте agile-методы. По возможности используйте средства DevOps на каждом этапе, например Fuge, Git/GiHub, Jenkins, Phantom или Kubernetes.

    Переход на микросервисы, как и любое преобразование ПО, способен сильно повлиять на качественные характеристики приложения:

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

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

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

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

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

    ***

    Технологии микросервисов развиваются сегодня весьма стремительно, в частности, получили развитие бессерверные вычисления — предоставление облачным микросервисом стандартных функций, которые можно использовать в приложениях для реализации необходимой бизнес-логики. Такие платформы могут называться «бессерверными» или предоставляющими «функции в виде сервиса» (Function-as-a-Service, FaaS): Amazon Web Services Lambda, Iron.io и Google Functions.

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

  • Оптимизируем производительность office 365 и больших профилей. Часть 2

    Оптимизируем производительность office 365 и больших профилей. Часть 2

    Области применения контейнеров Profile Container

    Контейнеры Profile Container — дополнительные диски VHD или VMDK, которые могут автоматически предоставляться через ProfileUnity. Нередко части профиля не могут размещаться только в ProfileDisk (обычно потому, что приложение запрещает ему быть частью пользовательского профиля), следовательно, должны быть сохранены на отдельном диске VHD или VMDK.

    Контейнеры Profile Container входят в определенные рекомендуемые варианты использования ProfileUnity. Их предпочтительно использовать в перечисленных ниже случаях:

    • Индексация Outlook — ProfileUnity предусматривает режим, в котором подготавливает контейнер профиля (VHD) для ведения индексации Outlook. Это удобно в средах виртуального рабочего стола, где индекс Outlook в противном случае непостоянен.
    • «Облачное» хранилище — такие решения, как Microsoft OneDrive, Dropbox, Amazon Drive/WorkDocs и Google Drive, идеальны для применения контейнера профиля VHD (а возможно, и VMDK). Нередко эти службы не позволяют сохранять данные на пути пользовательского профиля. Контейнеры Profile Container позволяют таким службам хранить в сети большой кэш данных, который считывается с высокой скоростью блочного доступа.

    Существует и несколько других факторов, которые необходимо учитывать, в том числе такие сложные варианты:

    • Хотите ли вы задействовать ProfileUnity в качестве средства репликации данных дополнительно к приведенному выше примеру?
    • Есть ли у вас неустойчивое соединение по сети Wi-Fi (это может привести к несогласованности ProfileDisk)?
    • Планируете ли вы архивировать данные с ноутбуков на сайт DR VD1?
    • Хотите ли вы обеспечить совместимость с Windows 7, 8.1 и 10, а также Windows Server 2008, 2012, 2016?
    • Имеют ли место множественные процедуры авторизации пользователя на одном компьютере или вам нужно несколько почтовых ящиков Outlook на одного пользователя?

    Рекомендации для Profile Portability

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

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

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

    Наборы правил Portability определяют, какие фрагменты следует или не следует сохранять в профиле. Специалисты Liquidware потратили несколько лет, чтобы составить и усовершенствовать наборы правил в соответствии с рекомендациями Microsoft.

    В результате пользователь может сделать постоянными только значимые компоненты профиля (экран 2).

    При настройке параметров с использованием встроенных шаблонов встроенные правила переносимости применяются внутри данного набора параметров, и от вас не требуется выполнять никаких действий (экран 3).

    Как часть шаблона в сочетании с Folder Redirection, эти правила переносимости сформируют ваш профиль на 95%. Потребность в настройке составит не более 5%, так как в наборе параметров данного типа будет учтено большинство, если не все элементы.

    При настройке последних пяти или менее процентов элементов необходимо знать, где приложения хранят свои параметры. Эти элементы могут быть расположены просто в appdata\Roaming или appdata\local. В этом случае воспользоваться режимом Folder Redirection.

    Если приложение использует для записи другие места (например, c:\Lotus\Notes), придется составить специальный набор правил Portability, такой как показан на экране 4.

    Объединение правил Portability, шаблона, прикладных правил в шаблоне и Folder Redirection обеспечивает все элементы, необходимые для обслуживания пользовательских профилей.

    Обработка после входа в Portability

    Начиная с версии ProfileUnity 6.5.5 применяется концепция Process Action after Login («Обработка после входа»), позволяющая значительно увеличить скорость входа (экран 5).

    Идея заключается в том что ProfileUnity по-прежнему использует правила Portability, описанные выше, но соответствующие элементы обрабатываются после входа в операционную систему. Это компенсирует время обработки подключения папок до того, как вы авторизовались в операционной системе. Одни элементы подходят для такого варианта, другие — нет.

    Удачные примеры для обработки после входа:

    • Приложение или параметр не связаны с процессом, запускаемым вместе с Windows или вашей процедурой входа, например Skype, Snag-it, Slack.
    • Приложение или параметр не связаны с процессом, и имеется огромный выходной файл. Обработка может быть выполнена после входа, но время завершения не будет оптимальным, например если имеются OST или PST-файлы или большие базы данных.

    Использование этого варианта с такими программами, как Google Chrome, Mozilla Firefox или Internet Explorer, может значительно ускорить процедуру входа и увеличить общую производительность авторизации в целом.

    Для активации этого режима достаточно просто выбрать дополнительные возможности при изменении параметра Portability и нажать Process Action after Login, как показано на экране 6.

    При использовании подобного подхода вы сосредотачиваетесь на одном приложении или параметре, обработка которого будет перенесена на завершающую часть процедуры входа. Это немного усложнит настройку, поскольку вам придется составить новый набор правил для каждого приложения, включаемого в обработку после входа. Некоторые из этих правил Portability могут быть построены в Internet Explorer или, возможно, вам придется создать специальный набор правил, как в примере с Lotus Notes.

    Использование триггеров

    Схема «события-триггеры» — последний вариант обработки параметров ОС и самый сложный из четырех способов передачи данных профиля в операционной системе. Часто при этом бывают необходимы события «открытие» и «закрытие», чтобы запустить и сохранить параметры приложения. Кроме того, требуется составить набор правил Portability для всех приложений, связанных с этими событиями открытия и закрытия. Как в случае с пост-обработкой, количество приложений зависит от того, как пользователь настроил набор правил. Чтобы задействовать точки триггера Trigger Points, необходимо иметь несколько элементов:

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

    Сначала необходимо указать точку триггера или событие в модуле настройки. Как показано на экране 7, тип триггера — Application Open («Приложение открыто»), и это приложение — Chrome.exe. Действие — восстановление Portability Restore. Обратное произойдет при закрытии приложения (действие — сохранение Portability Save).

    Далее мы должны настроить фильтр Trigger, который обозначает событие запуска триггера. Как показано на экране 8, системное событие Logon/Logoff («Вход/выход») не выбрано, поскольку не требовалось задействовать правило Portability на данном этапе. Необходимо было, чтобы обработка начиналась только по вызову точки триггера.

    Последнее — назначить параметру Portability фильтр Trigger в параметрах Portability (экран 9).

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

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

    Добавьте это правило Portability в новый набор (экран 11).

    Сохраните этот набор параметров в подпапке Trigger в каталоге инструментов ProfileUnity (экран 12).

    Используя дополнительные параметры в модуле Trigger Point Configuration Module, вы можете выбрать определенный INI-файл, который следует запустить (экран 13).

    Используя этот метод, вы запустите только один элемент в модуле Portability, а не несколько несвязанных элементов Portability.

    Точки Trigger Points предъявляют аналогичные требования к пост обработке, так как их обработка также выполняется после входа пользователя в среду.

    Удачные примеры обработки после входа:

    • Приложение или параметр не связаны с процессом, запускаемым вместе с Windows или при входе пользователя, например в Skype, Snag-it, Slack.
    • Приложение или параметр не связаны с процессом, и имеется огромный выходной файл. Обработка может быть выполнена после входа, но время завершения не будет оптимальным, например при наличии OST или PST-файлов или больших баз данных.

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

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

    Лучше вместе

    В некоторых случаях, когда возможности Portability недостаточны по причинам быстродействия или совместимости, можно объединить технологии ProfileDisk и Profile Portability. Как правило, сначала рассматриваются все варианты с Portability и Folder Redirection, а затем к ним добавляется ProfileDisk. Чтобы добавить ProfileDisk, достаточно активировать функцию, назначив ее группе пользователей и выполнив вход в систему.

    При работе с несколькими типами операционной системы или двумя либо несколькими рабочими станциями одновременно, необходимо настроить два или три диска. Для этого требуется подготовить различные «узловые» файлы и отдельные объекты групповой политики (GPO) для ссылки на них.

    Узловой файл ссылается на расположение ProfileDisk и группы, связанные с этим ProfileDisk.

    Как показано на экране 14, в области администратора Profile Unity вы можете указать расположение и группу.

    Затем загрузите нужный набор (nodes, xml) в папку ProfileUnity Tools. Если узлов несколько, то полезно иметь вложенные папки для разделения узлов.

    На экране 15 у нас имеется вложенная папка узлов, а также вложенные папки Site 1 и Site2 с файлом nodes.xml в каждом из этих расположений.

    При создании групповой политики для определенной группы машин (Site 1 на экране 16) вы можете указать соответствующий путь в параметре ProfileDisk Nodes Path (экран 17).

    Это политика на основе компьютеров, поэтому системы придется разделить между различными организационными подразделениями OU на основе версии операционной системы, или пулами.

    После того как файлы nodes.xml и объекты групповой политики окажутся на месте, просто перезагрузите рабочие станции, и ProfileDisk будет активирован.

    Чтобы отключить ProfileDisk, требуется удалить программное обеспечение ProfileUnity и файлы nodes.xml из исходного пути узлов. Затем программа ProfileUnity может быть удалена. Простое удаление файлов nodes.xml не приведет к отключению ProfileDisk. Сведения об удалении ProfileDisk можно найти в статье базы знаний по адресу: liquidwarelabs.zendesk.com/hc/en-us/articles/210637863- Removing- Profile Disk-formpersistent-desktops.

    Если возникли затруднения с выполнением процедуры – обратитесь за помощью к нам. Все будет сделано быстро и качественно.

  • Оптимизация производительности office 365 и больших профилей

    Эта статья посвящена внедрению технологий виртуализации рабочих столов. Мы рассмотрим два типа управления профилем с использованием ProfileUnity: Profile Disk и Profile Portability. В статье будут даны рекомендации для каждой технологии и перечислены случаи, когда их можно использовать вместе.

    ProfileUnity— полнофункциональное решение для унифицированного управления пользовательскими системами (UEM) с встроенной технологией ProfileDisk.

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

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

    1. ProfileDisk – профиль на основе виртуального диска, который представляет весь профиль как слой из подключенного VHD или VMDK пользователя.
    2. Profile Portability – решение для профилей на основе файлов и реестра, которое восстанавливает файлы при авторизации, после авторизации или при срабатывании триггеров среды исполнения.

    Основы ProfileDisk и Profile Portability

    Функциональность ProfileDisk не ограничивается простым перенаправлением папок профилей. ProfileDisk вступает в игру на ранних этапах процедуры авторизации Windows и выглядит для операционной системы Windows настолько «своим», что воспринимается как собственный профиль операционной системы. В результате удается избежать типичных проблем, связанных с перенаправлением профиля.

    Кроме того, ProfileDisk преодолевает недостатки, неизбежно свойственные очень большим профилям, в частности содержащим автономные или личные почтовые папки (например, для Microsoft Office 365 в режиме кэширования) или другие крупные файлы. Контейнеры Profile Container, состоящие из одного или нескольких дополнительных файлов VHD или VMDK, могут быть добавлены в такие приемники в пользовательском профиле, как Microsoft OneDrive, Dropbox, Amazon Drive или WorkDocs и др.

    ProfileDisk позволяет заставить пользовательский профиль функционировать устойчиво даже на удаленном рабочем столе, например в сеансе Citrix XenDesktop или VMware Horizon View. В итоге мы получаем очень быстрое время авторизации пользователя. Операционная система Windows полагает, что пользовательский профиль уже находится на компьютере, его не требуется извлекать и передавать по сети.

    Технология ProfileDisk успешно работает со стандартным методом управления профилем ProfileUnity, известным как Profile Bridge, за счет подключения функционального модуля Portability в ProfileUnity. Компонент Profile Portability представляет собой решение для управления профилем на основе файлов и реестра, которое восстанавливает файлы при авторизации, после авторизации или при срабатывании триггеров рабочей среды. Profile Portability также действует как посредник ProfileBridge между различными версиями Windows, предоставляя пользователям один унифицированный пользовательский профиль.

    Profile Portability изначально извлекает от 85 до 100% данных из профилей пользователей. Причина, по которой Portability не получает все сведения из профиля немедленно, заключается в том, что приложения не всегда записывают данные в пользовательский профиль. Но администраторы могут компенсировать этот изъян, применяя правило ProfileUnity Portability для пользователя или группы пользователей, чтобы выбрать другие файлы и сделать их переносимыми.

    Например, многие нестандартные приложения (Lotus Notes, Oracle, приложения собственной разработки и т. д.) ведут запись в папку Program Files, другие новые файлы Root или в System Root. Простые инструменты для работы с профилем не могут охватить эти области, поскольку сосредоточены на профиле Windows и папках Windows Shell. ProfileUnity легко получает данные из этих файлов с помощью набора правил охвата Portability, составление которых не вызывает затруднений.

    Технология Profile Portability предназначена не только для достижения настоящей переносимости, но и для ускорения процедуры авторизации и уменьшения сетевого трафика. Основные данные пользовательского профиля извлекаются и сжимаются (приблизительно в соотношении 50:1) в хранилище. Он восстанавливается на системе в известных каталогах Windows — даже между различными версиями операционной системы. Впоследствии по сети пересылаются только различия между файлами.

    Profile Portability и ProfileDisk могут обеспечить значительные преимущества при их совместном использовании в случае необходимости. Два компонента с первой авторизации пользователя работают согласованно, сохраняя весь профиль в файле VHD или VMDK ProfileDisk. Когда пользователь выполняет повторную авторизацию на любом настольном компьютере на предприятии, работающем с ProfileUnity, этот VHD или VMDK немедленно подключается при указании учетных данных для Windows.

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

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

    Таким образом, вы не можете учесть нестандартные приложения (Lotus Notes, Oracle, приложения собственной разработки и т.д.), которые ведут запись в папку Program Files, и новые файлы в корневой или системой папке. Существуют и другие ограничения, которые мешают пользователю полагаться на многоуровневый профиль. Приведем некоторые из них.

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

    Совместное применение

    При совместном использовании функциональность ProfileDisk и Portability позволяет быстро обрабатывать профиль в разных версиях Windows с различными форматами пользовательских профилей и гибко управлять профилем при необходимости. Однако такой вариант использования не всегда приемлем. Рекомендации для каждой технологии, приведенные ниже, помогут вам выбрать оптимальный подход для каждого пользователя.

    При совместном применении двух технологий типичный подход на предприятии выглядит следующим образом.

    ProfileUnity ProfileDisk мгновенно предоставляет профиль при авторизации пользователя, а затем Portability выполняет несколько очень простых действий, чтобы дополнить его нестандартными данными. В результате пользователи довольны быстрой процедурой авторизации и получают необходимые для работы данные приложений. Кроме того, ProfileDisk может применить полный набор правил переносимости ProfileUnity, чтобы обеспечить одновременные процессы авторизации и совместимость с различными версиями операционной системы (с мгновенной миграцией). Такое сочетание технологий обеспечивает высокую скорость и детализированное управление.

    Рекомендации для ProfileDisk

    Начнем с простой кнопки профилей, Data Disks. Она позволяет поместить данные профиля на диск, который подключается постоянно или перемешается вместе с вами с одного рабочего компьютера на другой, как в случае с ProfileDisk от Liquidware. Чтобы решить, подходит ли этот способ для вашей организации, следует учесть несколько факторов. Ниже перечислены примеры, когда стоит использовать ProfileDisk, а когда лучше отказаться от него.

    • Временная виртуальная операционная система Windows (только одна операционная система).
    • Режим кэширования Microsoft Office 365 или необычно большие файлы в папке AppData. В результате пользователь имеет большой профиль, обрабатываемый с помощью ProfileDisk.
    • Один пользователь на компьютер.
    • Одна процедура авторизации на пользователя:
      • стандартный временный шаблон в Windows;
      • перенаправление папки для пользовательского профиля;
      • вся папка AppData Roaming на диске или перенаправление папок;
      • вся папка Local AppData на диске или перенаправление папок (зависит от среды);
      • ProfileDisk для ускорения авторизации (подключение профиля вместо его загрузки);
      • параметры DPI должны быть в ntuser.dat во время входа;
      • параметры шрифта должны быть в ntuser.dat во время входа;
      • переменная среды %appdata% никогда не будет следовать перенаправлению папок и должна быть в ntuser.dat во время входа;
      • переменная среды %1оса1-appdata% никогда не будет следовать перенаправлению папок и должна быть в ntuser.dat во время входа;
      • резервное копирование и восстановления параметров Windows 10 Edge.

    В каких случаях применение ProfileDisk не рекомендуется:

    • Постоянная виртуальная операционная система Windows (возможный, но не самый удачный вариант).
    • Постоянная физическая операционная система Windows (возможный, но не самый удачный вариант).
    • Один пользователь, выполнивший вход на нескольких компьютерах.
    • Многосеансовые среды, такие как серверы терминалов, где пользователи работают со многими опубликованными приложениями (рабочими столами) на многих серверах.
    • Смешанные среды операционной системы (хотя использование ProfileDisk вместе с Profile Portability решает эту задачу).

     

    Если вы хотите легко, быстро и профессионально мигрировать в облако – обращайтесь, мы сделаем все за вас.

  • Как обеспечить максимальный uptime проекта?

    Как обеспечить максимальный uptime проекта?

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

    6 проблем снижения uptime

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

    1. Весь проект локализован в одном месте (облачный хостинг, дата центр)

    Бытует ошибочное мнение, что облачный хостинг не имеет привязки к железу, то есть инфраструктура в облаке просто не может упасть. Но реальность жестока, случаются и аварийные падения cloud (вспомните cloud4y или cloudmouse!). В результате – даунтайм на несколько часов.

    Подобная ситуация и с «земными» дата центрами: все серверы пользователь резервирует в одном месте. Как только случится авария на одном из них, недоступность может заразить не только несколько стоек, но и весь центр.

    Решение: попробовать наладить AWS-схему. Согласно ей, используется несколько availability zones, чем и достигается 100-процентный uptime.

    2.Нет адекватного дублирования на площадке-резерве

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

    • в конфигурации «кластер-данные в кластере» (для сложной площадки);
    • в файловой структуре (+ отслеживание отставания);
    • в конфигурации серверов;
    • при добавлении основных сервисов/проектов (+ отладка процессов контроля);
    • при подключении вторичных сервисов.
    • Для наибольшей эффективности не забываем о постоянном мониторинге всего!

    3.Не налажена регулярность переключений на площадку-резерв, не выполнено тестирование таких переходов

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

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

    4.Площадка-резерв локализована в одном месте (будь это канал либо регион облака)

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

    Выход: создать конфигурацию с площадкой-резервом на базе своего хостинга (здесь будут размещены штатные средства, помогающие в переключении на место-резерв) + со вторичной на базе другого хостинга.

    5.Одни и те же данные размещены и на площадке-резерве, и на основной

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

    Выход: продумать механизм отката продукта до предыдущей версии на еще одной площадке. Здесь в тему будет упомянуто резервное копирование – отложенная репликация на некоторый период времени (например, на 1 час). Такое решение поможет в момент аварии выполнить переход на ту БД, где ситуация еще не претерпела никаких изменений.

    6.Проект зависим от внешних сервисов

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

    Решение: дублирование критических внешних сервисов с последующим отслеживанием их доступности. И, конечно же, включение в план их переключений в случае аварийной ситуации.

    Надеемся, что наши рекомендации и советы помогут вам обеспечить 100% uptime проекта. Если желаете добиться максимально доступности вашего проекта, обращайтесь.

     

  • Хранение данных в «облаке»

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

    Помощь в построении облачной инфраструктуры, подбор и расчет оптимальной модели, обращайтесь office@itfb.com.ua

    Перечислим 10 факторов хранения данных в облаке:

    1. Хранение данных в «облаке» не гарантирует защиты от потери данных. Один из самых распространенных мифов об «облачном» хранилище состоит в том, что «облако» каким-то чудесным образом защищает от потери данных. Хотя поставщики «облачных» хранилищ обычно предоставляют различные инструменты для защиты данных, это не отменяет необходимости создавать обычные резервные копии.
    2. Возможны затраты, связанные с передачей данных. Каждый поставщик «облачных» служб хранения данных по-своему взимает оплату с пользователей, но хранение обычно оплачивается из расчета за количество гигабайтов в месяц. Некоторые поставщики даже умудряются устанавливать плату за загрузку, выгрузку или просто обеспечение доступа к вашим данным.
    3. Цена зависит от уровня хранения. Поставщики «облачных» служб хранения данных обычно предлагают несколько уровней хранения, а цена может заметно отличаться в зависимости от того, какой уровень вы выбираете. Например, терабайт на высокопроизводительном твердотельном запоминающем устройстве всегда будет стоить дороже, чем он же при хранении на уровне, который основан на стандартных вращающихся дисках.
    4. Стоимость хранения зависит от того, где вы живете. Когда вы передаете данные на хранение в «облако», вас обычно просят выбрать регион. Он соответствует местоположению центра хранения данных, где физически располагается хранилище. Цена за хранение может меняться от региона к региону, поскольку затраты на энергию, пропускную способность каналов и других ресурсов могут отличаться в разных частях света.
    5. Разрешения — ключ к безопасности. Во время размещения данных в хранилище — открытом, закрытом или гибридном — обратите внимание на применяемые разрешения. Неправильная система безопасности хранилища может означать, что любой, кто знает адрес URL или IP-адрес хранилища, сможет получить доступ к данным. Бывали случаи, когда данные оставались незащищенными просто потому, что организация не заблокировала внешний доступ к хранилищу.
    6. Управлять «облачной» системой хранения можно по-разному. Вам может быть предложено несколько вариантов для управления ресурсами «облачного» хранилища. Так, среди основных поставщиков «облачных» служб довольно распространенным является предоставление графического приложения как инструмента первичного управления хранилищем. Кроме того, они разрешают управлять хранением через интерфейс командной строки или предоставляют свой набор средств разработки.
    7. Не все хралища баз данных в «облаке» создаются одинаково. Многие поставщики «облачных» служб хранения данных выделяют несколько классов хранения. Категории хранения определяют, каким образом следует использовать систему хранения. Например, поставщик может предложить один класс хранения данных для общего применения, другой — для использования данных экземплярами виртуальной машины, а еще один класс хранения для долгосрочного архива данных. Выбор подходящего класса хранения для конкретной задачи гарантирует оптимальный режим работы.
    8. Вы можете копировать хранилище в разные зоны доступности. Некоторые поставщики «облачной» службы разрешают реплицировать хранилище из одной зоны доступности в другую. Этот тип репликации может помочь ускорить доступ к данным в других географических областях, поскольку копия данных размещается рядом с пользователями, которым нужен доступ. Репликация хранения также может применяться в целях обеспечения высокой доступности ваших данных.
    9. Вы можете использовать заранее установленные лимиты для управления затратами. У поставщика может быть предусмотрена оплата, связанная практически с каждой операцией по эксплуатации хранилища. Например, вы должны будете заплатить за загрузку данных, доступ к данным и даже за потребляемое данными пространство, которое никто не использует. Поскольку поставщики «облачных» служб хранения данных применяют формулы для составления счетов на оплату, точно оценить, сколько вы тратите на хранилище, может быть трудно. Однако некоторые поставщики «облачных» служб хранения данных дадут вам возможность настроить лимиты, которые не позволят «облачному» хранилищу «съесть» ваш бюджет. Эти лимиты принудительно останавливают доступ, как только ваши траты достигают определенного уровня.
    10. Вы можете усовершенствовать систему безопасности посредством настройки уведомлений. Иногда поставщики разрешают подписчикам настраивать уведомления, которые будут сообщать администратору о выполнении определенных действий. Например, вас могут уведомлять о том, что кто-то пытается получить доступ к какому-либо файлу или модифицировать данные в вашем архиве.

  • DRBD9 + Proxmox = надежное хранилище (II часть)

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

    Немного о DRBD

    Версия DRBD 8 работала по принципу сетевого зеркала RAID1. 9 версия получила два существенных «плюса»:

    • поддержку кворума;
    • репликацию с 2 и более нодами.

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

    Конфигурации DRBD: + iSCSI + LVM

    Получить отказоустойчивый iSCSI-таргет на основе DRBD9 вполне реально. Рассмотрим особенности iSCSI и LVM. Есть множество реализаций iSCSI, но они имеют общие характеристики:

    • высокая производительность;
    • обработка сетевых сбоев;
    • поддержка авторизации.

    Что касается LVM, то Proxmox прекрасно их задействует, используя свои стандартные драйверы. Но «минусы» есть и здесь. Размер виртуального диска ограничивается свойствами LVM-группы, поэтому и гибкость будет ниже, чем Ceph. К тому же производительность в случае применения снапшотов снижается. Хотя простота решения LVM привлекательна для многих.

    Получить отказоустойчивый iSCSI-таргет на 3 ноды с распределенными устройствами-DRBD можно в три шага.

    • Первый шаг: iSCSI-таргет подключается ко всем нодам.
    • Второй шаг: он вместе с LXC-контейнером запускается поверх устройства- DRBD.
    • Третий шаг: на iSCSI-таргете создается LVM-группа.

    Еще один «плюс» этого решения: если возникнет необходимость переезда на другую ноду LXC-контейнера, это можно сделать сразу вместе с iSCSI-таргетом.

  • DRBD9 + Proxmox = надежное хранилище

    Тем, кто ищет надежное software-defined хранилище, стоит обратить внимание на DRBD9. Его предыдущая версия не пользовалась особой популярностью по ряду причин: отсутствовала поддержка репликации до двух узлов, проблемы со spli-brin. На сегодняшний день DRBD постоянно обновляется разработчиками LINBIT.

    Особенности DRBD9

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

    • diskless-ноды;
    • RDMA;
    • использование снапшотов;
    • онлайн-миграция;
    • поддержка до 32 реплик.

    Следует отметить переходный этап в разработке инструментария интегрирования новых версий продукта от LINBIT с OpenStack, Kubernetes, OpenNebula, Proxmox. В дальнейшем нежелательными для использования будут объявлены DRBDmanage с Linstor.

    Proxmox + DRBD9

    В Proxmox имеется готовый интерфейс, отличающийся простотой и многофункциональностью. Отметим:

    • кластеризацию прямо из коробки;
    • поддержку механизма fencing на softdog;
    • минимальные таймауты во время переключения (в случае применения контейнеров-LXC).

    DRBD9 можно использовать, чтобы получить отказоустойчивый NFS-сервер. Для этого организуем NFS-доступ на общий раздел, что и позволит добиться конкурентного доступа к системе файлов хранилища сразу с нескольких серверов. Общий алгоритм на 3 ноды:

    • на каждой из нод – распределенное устройство-DRBD с файловой системой ext4;
    • один из серверов определяется как мастер;
    • на мастере в контейнере-LXC запускается NFS-сервер.

    Ноды через NFS обращаются к устройству-DRBD. Мастер можно переместить на другую ноду сразу с NFS-сервером. К тому же отпадает необходимость в сложных кластерных файловых системах с DLM.

    «Плюсы» такого решения:

    • хранение каких-либо файлов, бэкапов, виртуальных дисков;
    • организация ReadWriteMany доступа для PersistentVolumes (с Kubernetes).

    Еще одним преимуществом DRBD9 является упрощение функциональности: автоматическое ролевое переключение с Primary на Secondary с помощью миграции в интерфейс Proxmox контейнера с NFS-сервером. Объясняем: при монтировании на ноде DRBD, оно автоматически получает статус Primary. То есть смонтировать его уже на другой ноде не получится, выдаст ошибку доступа. Подобное блокирование гарантирует защиту от одновременных доступов. Если контейнер будет остановлен, то устройство- DRBD будет размонтировано и станет Secondary.

    Также хорошо интегрируется специальный готовый плагин DRBDmanage. Но замечен и ряд «минусов»:

    • нельзя использовать на ноде больше одного пула;
    • controller volume размещается только на стандартном LVM;
    • замечены dbus-глюки.

    Перечисленные недостатки привели к появлению Linstor: нарезает на нодах LVM/ZFS разделы, распределяет DRBD-конфиги. Он в полной мере интегрируется с Kubernetes.
    Суть Proxmox – его использование в качестве cluster-manager. При этом отдельно взятый LXC-контейнер будет играть роль сервиса, который запустится в HA-кластере. К нему в комплектацию добавится и соответствующая корневая система. В этом варианте он установится внутри контейнера единоразово, а не на каждом из серверов отдельно.

     

  • Тестирование VMware vSAN: процесс, результат, выводы

    Представьте ситуацию: на собранном из Intel NUC дата-центре размещается программная СХД. Она отличается стойкой неубиваемостью (подтверждено на практике уборщицей, повредившей кластер). Чтобы утвердиться в этом мнении окончательно, было решено vSAN протестировать не на одном сервере, а на нескольких с хорошей конфигурацией. Это решение помогло оценить степень отказоустойчивости и производительность. Делимся полученными результатами.

    Особенности vSAN и возможные проблемы

    Что же собой представляет VMware Virtual SAN для виртуальных машин? Простыми словами: это серверный кластер. Можем перечислить его особенности:

    • гипервизор с запуском сразу с «железа»;
    • «горячие» данные на HDD, медленные данные на SSD;
    • независимые компоненты;
    • отдельно сконфигурированное хранилище на базе (например, SAN).

    Добавьте к этому, что не все элементы системы, изготовлены одним производителем. «Полнейший зоопарк!» – скажете вы.

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

    В нашем случае на VMware Virtual SAN развертывается инфраструктура именно гиперконвергентная. Основное в таком симбиозе – плодотворная интеграция с Virtual Sphere (сегодня она лидирует). Благодаря этому, на серверах можно за несколько минут развернуть программное хранилище, оптимально распределить нагрузку, кешировать операции «чтение-запись», управлять операциями «ввода-вывода» на низком уровне. К этому еще плюсуйте минимальный объем нагрузки, оказываемой на процессор и память. Следует отметить и некоторое снижение прозрачности системной функциональности, но все работает на уровне automagically.

    All-flash vSAN: тестирование

    Предлагаем рассмотреть, как vSAN используется в качестве all-flash (гибридного хранилища). В нашем случае конфигурация чистая. Весь расчет на то, что она оптимально подойдет в соотношении своих качеств производительности и стоимостью. Сравнивая ее с гибридной конфигурацией, когда используются магнитные диски, заметна низкая суммарная емкость. Но есть ли возможность этого избежать, хотя бы частично? Для проверки задействовали такую схему: erasure coding+дедупликацию+компрессию «на лету». Получили: эффективность хранения приближена к гибридным решениям, но с более быстрой реакцией при минимальном overhead.

    Чтобы протестировать производительность, взяли ПО от HCIBench (v1.6.6), а именно инструмент VDbench для синтетического нагрузочного тестирования. С его помощью автоматизируется процесс создания нескольких виртуальных машин, и в то же время упрощается автоматизация тестирования в кластере HCI. Набор тестов был одинаковым для различных профилей нагрузки. Выполнялась эмуляция 3-х разных объемов активных данных, чтобы проверить поведение системы, эффективность механизма управления данными.

    Результаты

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

    • беспроблемная синхронизация;
    • запуск машин без задержек;
    • не нарушена целостность данных.

    Общие рекомендации по vSAN

    Практическая реализация vSAN имеет право на жизнь. Но стоп-фактор в виде высокой цены на лицензию останавливает многих. При создании инфраструктуры «с нуля» общепринятая, со сходной конфигурацией СХД, может по стоимости получиться тоже не маленькой. Но отличия, все же, будут – сниженная степень гибкости администрирования и масштабирования.

    В случае с решением на GlusterFS либо на Ceph есть ряд преимуществ vSAN:

    • тесное интегрирование с нужными компонентами;
    • простое администрирование;
    • удобное развертывание;
    • на небольшом количестве узлов производительность выше.

    Сократить затраты тоже можно: существует специальная схема лицензирования, рассчитанная на определенное количество машин. А чтобы оптимально распределить трафик для vSAN all-flash, по архитектуре потребуется 10 Гб интернета с двумя линками на один узел. Таким образом, экономится и место в стойке, и можно отказаться от Fibre Channel.

    Применение vSAN для филиалов – еще один прекрасный повод к его развертыванию. Это позволит получить всего на 2-х узлах отказоустойчивое хранилище, а также эти узлы «зеркалить».

  • Установка PHP 7 на CentOS 7

    С репозитория centos7 по умолчанию устанавливаетсяPHP 5.4 который на данный момент не поддерживается разработчиками. Что бы использовать новые функции и применять обновления безопасности, лучше использовать новую версию PHP, желательно последнюю.

    Установка PHP 7 в CentOS 7

    1. Для получения возможности установки PHP 5.7 нужно иснталировать и использовать репозиитории EPEL и Сделать это можно таким способом:
    yum install http://rpms.remirepo.net/enterprise/remi-release-7.rpm
yum install https://dl.fedoraproject.org/pub/epel/epel-release-latest-7.noarch.rpm
    1. Далее установим утилиту yum-utils, данная утилита содержит програмки с помощью которых можно управлять репозиториями. Таким образом расширим функционал yum, имеющийся по умолчанию.

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

    yum install yum-utils
    1. Теперь испльзуем одну из программ данного пакета yum-config-manager. С её помощью можно указать репозиторий который будет использоваться по умолчанию для определенного ПО, в нашем случае Зделать это можно таким способом:
    yum-config-manager --enable remi-php70

    Если необходимо поставить PHP 7.1 и 7.2 , соответвенно команды будут следующие

    yum-config-manager --enable remi-php71 
yum-config-manager --enable remi-php72
    1. Приступим непосредственно к установке пакета, с необходимыми модулями
    yum install php php-mcrypt php-cli php-gd php-curl php-mysql php-ldap php-zip php-fileinfo

    После установки можем проверить текущую версию PHP в Centos 7

    php –v

    Нужна помощь в администрировании серверов, обращайтесь office@itfb.com.ua