Target root folder

Target root folder Техника

After installation, the package.json must contain a command build-storybook. This command will be used to generate production build / static files of Storybook




Create gh-pages branch

There are many ways to setup Github Pages such as:

  1. Use existing branch and target root folder or /docs folder
  2. Create a new branch gh-pages and target root folder or /docs folder

I prefer (2) using root folder in this case because for (1) you needs to track static files of Storybook in Github which I feel unnecessary.

Ensure you have created the gh-pages branch via Github UI or CLI.

Then from Github Repository Settings, set the source to target gh-pages and select root folder. You’ll also see the Github Pages URL on this page.

storybook github pages setting

Create Storybook Github Action workflow

Now create a new file .github/workflows/storybook.yml, and define Github Actions below





main # if any push happens on branch `main`, run this workflow. You could also add `paths` to detect changes in specific folder





Checkout


Install and Build


npm run build-storybook


Deploy



storybookstatic # output folder from `npm run build-storybook`

Publish Storybook

Push any change to main branch to trigger Storybook deployment

storybook github pages deployed

See the example Github repository

This feature allows Group data and files to be selected and then copied to a new or existing Group.

This Group data can include:

  • Security Data
  • Group Tables
  • Projects with or without Rule Revisions
  • Captured Models
  • Released Models
  • Released Emails
  • Specifications

This feature is designed to aid with:

  • Performing backups of Group and Project information.
  • Moving versions of implementations between deployments (e.g. development, staging and production).

This feature works using DriveWork’s own API to copy data. As such, any additional (custom) data in the group databases will not be copied.

How To Use Copy Group

Please see the topic How To Use Copy Group for a step by step guide through the Copy Group wizard.

Select Target Group

This step is for selecting or creating the Group that you will copy Group data to.

You will have to login to the Target Group so that DriveWorks can check existing data in the Target Group and be able to add in your new data.

  1. Click Browse to select the Target group (the group the current group will be copied into).
  2. Select Create a new group or Open an existing group.

    Selecting different group types for the source and target will upscale or downscale the data accordingly.

    • When the source is a Shared Group and the Target is an Individual group, the data will be downscaled.
    • When the source is an Individual Group and the Target is a Shared Group, the data will be upscaled.
  3. Once the target group has been opened and you have returned to the Copy Group wizard, ensure the Group Connection indicator shows a successful connection.
    Target root folder

    If connection is not successful click the Retry button.

  4. Once you have successfully connected to the target group click Next.

Use Configuration (Optional)

Configurations are XML files created when previously using the Copy Group Tool. The files contain all the selection data and options used when creating a copied Group.

This step allows you to select one of those Configuration file to use when creating a Copied Group.

Clicking Browse will allow you to select a Configuration file to use using the file explorer.

With the Configuration file uploaded it will use the selections in it to rerun the Copy Group feature.

Select Projects

This step allows you to select what projects should be marked for copying.

Rule history can be copied for each project individually. This can increase the time it takes to copy the project, depending on the number of times the project’s rules have been edited. You should consider not copying rule revision data when using this feature to copy to between environments, as you will not need this information in say a production environment.

Projects will either be created or overwritten in the target group as need be.

In order to save time, DriveWorks checks to see if a project has actually been modified compared to the target group before copying. This is done by checking the project file’s modified date. You can see the result of this check on the summary step. This check only happens when copying to a group that already has a matching project (based on a unique ID that each project is created with and its name).

It’s possible to have conflicts when copying a project, such as having a project with the same name (but actually a different project). DriveWorks can detect this and will warn you of the issue (on the summary step) and not perform the project copy (though it will not prevent the entire group copy process).

The target group will have the project file location set to be relatively the same as the source group’s location. I.e. relative to the source root copy folder and the target’s root folder — set in the additional options step.

Permissions for the project will also be copied over if the project is selected and you choose to copy security information. This will only happen for teams that are new to the target group though. I.e. existing team’s permissions will not be changed.

Project information such as whether or not it is deployed or hidden is also copied.

Note that it’s possible to not select any projects, if you only want to copy other information in the group.

  1. Check the box next to each project that is to be copied.

    All projects can be selected by checking the box next to the Project Name column heading.

  2. Check the box in the rule history column. Leave unchecked if rule history is not required.

    Rule history for all projects can be selected by checking the box next to the Rule History column heading.

Select Group Tables

This step specifies what group tables should be copied to the target group.

The target group table will be created or overwritten as need be.

The target group table will be overwritten if the name matches the source’s name.

Permissions for the group will be copied over for new teams if you choose to copy group security information.

  1. Check the box next to each group table that is to be copied.

    All group tables can be selected by checking the box next to the Group Table Name column heading.

Component Selection Type

This step allows you to choose the method of component selection.

  • Automatically select all components in the selected Projects.

    All components that have been added to the selected projects will be included in the dataset.

  • Manually select components.

    Components to be included in the dataset will need to be manually selected from the next step.

  • Automatically select components: Any new component sets added to any of the selected projects or models added to any existing component sets will be included in any dataset produced from the configuration file.
  • Manually select components: When Top Level Components are checked any new models added to any selected component sets will be included in any dataset produced from the configuration file.

Captured Components

Only displayed if «Manually select components» was selected in the previous step.

The Captured Components step allows for selecting what captured components to copy.

Components are matched based on their unique identifier that is created when a component is created.

A component can be copied to a target group and then copied again to the same group (with new capture info etc), so long as the path remains the same from where it was moved last time (or doesn’t change when moving).

Components will be copied to directories relative to the target copy folder based on the relative path to the source copy folder.

Information on what will happen when a component is copied can be found on the summary step.

You might find it helpful to filter or order the list by the path column. Using the check all command only checks the items that are currently visible based on the filter.

  1. Check the box next to each captured component that is to be copied.

    All captured components can be selected by checking the box next to the Component Name column heading.

Additional Options

The Additional Options step allows root folders to be chosen and additional group data to be selected for copying.

Source Root Folder

By default the source root folder will be set to the Group Content Folder of the current group.

When copying a specific project out of the current group this folder may need to be changed to the root location of all files for that project.

If the group being copied contains files that are not located relative to this location, browse to a common root location where all files can be located.

Target Root Folder

This is where all copied files will be placed.

This should be an equivalent location to the target files as the source root folder is for its files.

Copy All Specifications

Checking this option will copy all data for each specification stored in the source group.

Specific specification files can be reviewed and deselected in the File Selection step.

Copy All Reports

Checking this option will copy all specification report data stored in the source group.

This can add significant time to your copy process and should only be if explicitly desired.

Copy All Tasks

Checking this option will copy any tasks that only DriveWorks Autopilot can process (i.e. email sending, triggered actions etc.).

Copy All Released Files and Information

Checking this option will copy all released files and information for each model that has been created for a specification..

Copy All Reports

Checking this option will copy all model report data stored in the source group.

File Selection

The File Selection step shows all physical files stored within the source root folder. It allows for you to pick what files will be copied over.

Note that if a file is included but it’s information in the group is not then it will just be a file copy. Likewise, you can copy information about a file but then not copy the file. This can be the case with specifications and we leave it to you to decide if you want this or not.

Sometimes file copies are redundant and as such might not be done. You can see the state of this on the summary step.

Some of these may be pre-selected based on the options chosen from the previous steps.

These can include:

  • Project files
  • Models and Drawings created for a specification
  • Whether or not the specification folder will be copied
  • [Included] — Is shown next to a file or parent folder of anything that is explicitly included in the copy.
  • [Excluded] — Is shown next to a file or parent folder of anything that is explicitly excluded from the copy.
  • [Locked] — Is shown next to a file or folder that cannot be changed.

This state can be applied to folders and all sub files and folders will inherit that value until something else explicitly has a different state. This allows for such situations as only copying a child folder and none of the files above it etc.

There are a number of commands to the right side of the file tree:

Show In Explorer — Will open Windows Explorer at the location of the selected file or folder.

Toggle Excluded — Will toggle all selected items between an explicit excluded state.

Toggle Include — Will toggle all selected items between an explicit included state.

Refresh — Will refresh the file tree to show new or deleted items since it was last loaded. Options will be maintained through refreshing.

Hide Excluded — Will hide all excluded files and folders from the file tree.

Summary

The Summary step allows a review of all of the tasks that will be performed from the previous selections made.

Дополнительно:  Не работают приложения Microsoft после сброса Windows: почему и что делать

This should be reviewed to ensure that it is doing what you expect.

Progress

The wizard will report on each process involved in the copying of the group.

This can be stopped at anytime by clicking the Stop button. Note that it will not reverse anything that has happened during the copy process so far.

There is a 3 second grace period when entering this step before it will start doing anything.

Once complete click the Finish button to close the wizard.

Vagrant is a command-line utility used to manage the lifecycle of virtual machines.

PyCharm provides a full integration with Vagrant allowing you to configure the Vagrant virtual environment, control the behavior of virtual machines, and execute Vagrant commands from within your project.

  • : the main configuration file that defines the Vagrant environment, stores all the configuration for the virtual boxes and tells Vagrant how to work with virtual machines.

  • : a virtual sandbox that contains a preconfigured virtual machine. Vagrant works with different providers of virtual boxes, such as Oracle’s VirtualBox, VMWare or AWS.

  • : a virtual machine.

In this article, we will explain how to initialize the Vagrantfile, specify the virtual box, run and interact with the virtual machine from PyCharm.

Prerequisites

  1. Install and enable plugin as described in Installing plugins from JetBrains repository.

  2. Install Vagrant and Oracle’s VirtualBox applications.

  3. Make sure virtualization is enabled on your computer.

Initialize the Vagrantfile

To start working with Vagrant, you need to initialize the Vagrantfile.

  • From the main menu, choose and select the target root folder from the opened window.

In the tool window Alt+1, switch to the view and double-click the to open it in the embedded editor.

Vagrantfile

Specify the virtual box

As an example, we will specify the ubuntu/trusty64 box. It contains a basic Ubuntu virtual machine. You can specify any other virtual box based on your needs. To find a list of available virtual boxes, refer to Discovering Vagrant Boxes.

    • : ubuntu/trusty64

    • : https://app.vagrantup.com/ubuntu/boxes/trusty64

    add the virtual box to Vagrant

Once the initialization is completed and virtual box is specified, you are ready to deploy and run the virtual machine.

Launch an instance

  • Terminal output for Vagrant up
  • From the main menu, choose .

SSH into a running machine

When the virtual machine is launched, it runs on a backend. To SSH into a running machine:

Vagrant commands to control an instance

To control an instance, use Vagrant commands. They can be run either from (Alt+F12) or from the main menu.

In this article, we show only the most important commands to work with the virtual machine. To find a full list of available Vagrant commands, refer to Command-Line-Interface.

  • suspending an instance pauses all the processes and saves the current state of a virtual machine.

    Run vagrant suspend in or select from the main menu.

  • resuming an instance brings up a previously suspended virtual machine.

    Run vagrant resume in or select from the main menu.

  • reloading an instance is required when you’ve made changes to the Vagrantfile and need Vagrant to reload the current virtual environment and its configuration.

    Run vagrant reload in or select from the main menu.

  • shutting down an instance stops the running virtual machine.

    Run vagrant halt in or select from the main menu.

  • destroying a virtual machine is important when you need to remove everything related to the previously created environment. All the resources provisioned during the creation of an instance are removed.

    Run vagrant destroy in or select from the main menu.

Last modified: 21 June 2023


Vagrant is a command-line utility used to manage the lifecycle of virtual machines.

IntelliJ IDEA provides a full integration with Vagrant allowing you to configure the Vagrant virtual environment, control the behavior of virtual machines, and execute Vagrant commands from within your project.

  • : the main configuration file that defines the Vagrant environment, stores all the configuration for the virtual boxes and tells Vagrant how to work with virtual machines.

  • : a virtual sandbox that contains a preconfigured virtual machine. Vagrant works with different providers of virtual boxes, such as Oracle’s VirtualBox, VMWare or AWS.

  • : a virtual machine.

In this article, we will explain how to initialize the Vagrantfile, specify the virtual box, run and interact with the virtual machine from IntelliJ IDEA.

Prerequisites

  1. Install and enable plugin as described in Installing plugins from JetBrains repository.

  2. Install Vagrant and Oracle’s VirtualBox applications.

  3. Make sure virtualization is enabled on your computer.

Initialize the Vagrantfile

To start working with Vagrant, you need to initialize the Vagrantfile.

  • From the main menu, choose and select the target root folder from the opened window.

In the tool window Alt+1, switch to the view and double-click the to open it in the embedded editor.

Specify the virtual box

As an example, we will specify the ubuntu/trusty64 box. It contains a basic Ubuntu virtual machine. You can specify any other virtual box based on your needs. To find a list of available virtual boxes, refer to Discovering Vagrant Boxes.

    • : ubuntu/trusty64

    • : https://app.vagrantup.com/ubuntu/boxes/trusty64

    add the virtual box to Vagrant

Once the initialization is completed and virtual box is specified, you are ready to deploy and run the virtual machine.

Launch an instance

  • Terminal output for Vagrant up
  • From the main menu, choose .

SSH into a running machine

When the virtual machine is launched, it runs on a backend. To SSH into a running machine:

Vagrant commands to control an instance

To control an instance, use Vagrant commands. They can be run either from (Alt+F12) or from the main menu.

In this article, we show only the most important commands to work with the virtual machine. To find a full list of available Vagrant commands, refer to Command-Line-Interface.

  • suspending an instance pauses all the processes and saves the current state of a virtual machine.

    Run vagrant suspend in or select from the main menu.

  • resuming an instance brings up a previously suspended virtual machine.

    Run vagrant resume in or select from the main menu.

  • reloading an instance is required when you’ve made changes to the Vagrantfile and need Vagrant to reload the current virtual environment and its configuration.

    Run vagrant reload in or select from the main menu.

  • shutting down an instance stops the running virtual machine.

    Run vagrant halt in or select from the main menu.

  • destroying a virtual machine is important when you need to remove everything related to the previously created environment. All the resources provisioned during the creation of an instance are removed.

    Run vagrant destroy in or select from the main menu.

Last modified: 07 February 2023


Vagrant is a command-line utility used to manage the lifecycle of virtual machines.

GoLand provides a full integration with Vagrant allowing you to configure the Vagrant virtual environment, control the behavior of virtual machines, and execute Vagrant commands from within your project.

  • : the main configuration file that defines the Vagrant environment, stores all the configuration for the virtual boxes and tells Vagrant how to work with virtual machines.

  • : a virtual sandbox that contains a preconfigured virtual machine. Vagrant works with different providers of virtual boxes, such as Oracle’s VirtualBox, VMWare or AWS.

  • : a virtual machine.

In this article, we will explain how to initialize the Vagrantfile, specify the virtual box, run and interact with the virtual machine from GoLand.

Prerequisites

  1. Install and enable plugin as described in Installing plugins from JetBrains repository.

  2. Install Vagrant and Oracle’s VirtualBox applications.

  3. Make sure virtualization is enabled on your computer.

Initialize the Vagrantfile

To start working with Vagrant, you need to initialize the Vagrantfile.

  • From the main menu, choose and select the target root folder from the opened window.

In the tool window Alt+1, switch to the view and double-click the to open it in the embedded editor.

Specify the virtual box

As an example, we will specify the ubuntu/trusty64 box. It contains a basic Ubuntu virtual machine. You can specify any other virtual box based on your needs. To find a list of available virtual boxes, refer to Discovering Vagrant Boxes.

    • : ubuntu/trusty64

    • : https://app.vagrantup.com/ubuntu/boxes/trusty64

    add the virtual box to Vagrant

Once the initialization is completed and virtual box is specified, you are ready to deploy and run the virtual machine.

Launch an instance

  • Terminal output for Vagrant up
  • From the main menu, choose .

SSH into a running machine

When the virtual machine is launched, it runs on a backend. To SSH into a running machine:

Vagrant commands to control an instance

To control an instance, use Vagrant commands. They can be run either from (Alt+F12) or from the main menu.

In this article, we show only the most important commands to work with the virtual machine. To find a full list of available Vagrant commands, refer to Command-Line-Interface.

  • suspending an instance pauses all the processes and saves the current state of a virtual machine.

    Run vagrant suspend in or select from the main menu.

  • resuming an instance brings up a previously suspended virtual machine.

    Run vagrant resume in or select from the main menu.

  • reloading an instance is required when you’ve made changes to the Vagrantfile and need Vagrant to reload the current virtual environment and its configuration.

    Run vagrant reload in or select from the main menu.

  • shutting down an instance stops the running virtual machine.

    Run vagrant halt in or select from the main menu.

  • destroying a virtual machine is important when you need to remove everything related to the previously created environment. All the resources provisioned during the creation of an instance are removed.

    Run vagrant destroy in or select from the main menu.

Last modified: 07 February 2023

Distributed File System. Архитектура и базовые понятия

Распределенная файловая система (Distributed File System, DFS) серверная технология Microsoft, предназначенная для упрощения доступа к общим файловым ресурсам, распределенным по сети. С помощью DFS можно объединять в единую логическую структуру файловые ресурсы, физически находящиеся на различных серверах, а также производить между ними репликацию.

DFS — технология не новая древняя как говно мамонта, она известна еще со времен Windows NT. Хотя термины DFS и Distributed File System появились несколько позднее и относятся к Windows 2000 и 2003. А в Windows 2003 R2 компания Microsoft представила новое пространство DFS-имен, а также улучшенный механизм репликации. Новое пространство DFS-имен называется DFS-N (DFS-Namespace), а новый механизм репликации — DFS-R (DFS-Replication). Именно эти две составляющих и образуют на данный момент функционал DFS.

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

Базовые понятия

Чтобы понимать, как работает пространство имен DFS, разберем основные понятия DFS на следующем примере.

общая схема работы DFS

DFS namespace (Пространство имен DFS)

Единый виртуальный каталог, содержащий ссылки на общие папки, расположенные на разных файловых серверах. Пространство имен состоит из корня (root), ссылок (folders) и целевых объектов (folder targets). Пространство имен DFS может быть двух типов: автономное (Standalone) и доменное (Domain-based).

У Standalone DFS namespace сведения о конфигурации хранятся локально на корневом сервере, в системном реестре. Путь для доступа к корневому каталогу или ссылке начинается с имени корневого сервера. Автономное пространство имен располагается только на одном сервере и не является отказоустойчивым. Если корневой сервер недоступен, все пространство имен DFS также становится недоступным.

У Domain-based DFS namespace конфигурация хранится в Active Directory. Путь для доступа к корневому каталогу или ссылке начинается с имени домена. Несмотря на то, что в нашем примере показан только один сервер пространства имен, доменное пространство имен можно размещать на нескольких серверах, чтобы повысить доступность пространства имен. Это позволяет обеспечить отказоустойчивость и распределить нагрузку между серверами.

Дополнительно:  Как запретить пользователю root заходить по ssh

(Корень пространства имен)

Базовая или начальная точка, от которой начинается отсчет пространства имен. В зависимости от типа корень доступен по адресу \\ServerName\RootName (Standalone) или \\DomainName\RootName (Domain-based). В нашем примере корень DFS доступен по адресу \\Contoso\Public.

(Сервер пространства имен)

Сервер пространства имен (или корневой сервер) — физический сервер, на котором содержится пространство имен DFS. Сервер пространства имен может быть как рядовым сервером, на котором установлена роль DFS Namespace, так и контроллером домена.

Ссылка в пространстве имен DFS, указывающая на целевую папку (или папки). Папки без конечных объектов (напр. папка Software) образуют структуру и иерархию в пространстве имен, а папки с целевыми объектами-папками (напр. папка Training Guides) предоставляют пользователям доступ к фактическому содержимому. Когда пользователь открывает папку, содержащую конечные объекты-папки в пространстве имен, клиентский компьютер получает направление (referral), которое прозрачно перенаправляет клиентский компьютер к одному из целевых объектов.

(Целевой объект-папка)

Ссылка на общий файловый ресурс, находящийся на определенном файловом сервере и доступный по пути UNC (Universal Naming Convention). Например общая папка \\FS2\Training на сервере FS2.

Именно целевой объект-папка является конечной целью пользователя, поскольку в нем находятся нужные ему данные. Одна ссылка может указывать как на один, так и на несколько целевых объектов. К примеру, папка с именем Training Guides имеет один целевой объект-папку, а папке Tools соответствуют два целевых объекта на разных серверах. И при обращении к папке Tools пользователь, в зависимости от своего местонахождения, будет перенаправляться в общую папку \\FS1\Tools или \\FS2\Tools.

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

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

Роли клиента и сервера

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

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

Корневые сервера, также называемые корневыми целями (Root targets) — физические сервера, на которых хранятся доменные или автономные пространства имен. В качестве корневого сервера DFS может выступать компьютер с серверной ОС, клиентские операционные системы могут быть только клиентами. Корневые серверы играют в DFS следующие роли:

• Для автономных пространств имен метаданные файловой системы DFS хранятся в реестре корневых серверов. Метаданные DFS состоят из информации обо всем пространстве имен, включая корневой каталог, корневые целевые объекты, ссылки, целевые объекты ссылок и параметры. Для доменных пространств имен метаданные DFS хранятся в Active Directory, однако на корневых серверах метаданные DFS также хранятся в оперативной памяти.

• На корневых серверах размещаются корневые папки (root folders) и подпапки (folders), соответствующие ссылкам в пространстве имен DFS.

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

Контроллеры домена играют важнейшую роль в функционировании DFS:

• Клиенты DFS обращаются к контроллерам домена, чтобы получить список доверенных доменов и контроллеров домена для этих доменов.

• Когда клиент DFS впервые пытается получить доступ к доменному пространству имен DFS, контроллер домена предоставляет клиенту список корневых серверов. Этот список корневых серверов известен как корневое направление (root referral).

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

• Всякий раз, когда администратор вносит изменения в доменное пространство имен DFS, это изменение выполняется на контроллере домена с ролью , а затем с помощью репликацию Active Directory реплицируется на другие контроллеры домена.

• На контроллерах домена хранится информация о сайтах Active Directory и межсайтовых связях (site links). DFS использует эту информацию при сортировке целевых объектов в порядке наименьшей стоимости. Так в нашем примере папка Tools находится на двух разных серверах, расположенных в двух разных сайтах (London и New York). В зависимости от того, где находится клиент, он получит ссылку на ближайший к нему сервер.

Целевые объекты-папки являются ссылками на общие папки (или подпапки внутри общих папок) на файловом сервере. В роли источника ссылки может выступать любая ОС с сетевой файловой системой, к которой можно обратиться через путь UNC, например Windows (SMB) или Linux (NFS). Путь UNC, указанный в ссылке, может вести к общим папкам в любой рабочей группе, общим папкам в том же домене, что и пространство имен, общим папкам в доверенных доменах и общим папкам в доверенных лесах. Также целевой объект может быть путем DFS в другом пространстве имен.

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

Архитектура DFS

С ролями все более менее понятно, переходим к их взаимодействию.

Компоненты архитектуры DFS на клиентах DFS, корневых серверах и контроллерах домена, а также их взаимодействие показаны на следующих рисунках.

На первом рисунке архитектура DFS контроллера домена упрощена, чтобы показать только объект DFS.

схема взаимодействия между клиентом и корневым сервером

На втором рисунке показана архитектура DFS контроллера домена и упрощенное представление архитектуры клиента и корневого сервера DFS.

Обратите внимание, что контроллеры домена и корневые сервера используют похожую архитектуру DFS. Это связано с тем, что контроллеры домена играют определенную роль в направлении клиентских компьютеров к корневым серверам домена. Кроме того, контроллеры домена могут размещать пространства имен и выполнять роль корневого сервера. В этом случае контроллер домена также размещает кэш метаданных DFS (независимо от типа пространства имен) и автономные метаданные DFS в своем реестре (для автономных пространств имен).

схема взаимодействия клиентом, корневым сервером и контроллером домена

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

Метаданные DFS — cведения о пространстве имен DFS. Состоят из информации обо всем пространстве имен, включая корневой каталог, корневые целевые объекты, ссылки, целевые объекты ссылок и параметры. Для доменного DFS метаданные хранятся в Active Directory, в специальном объекте DFS, соответствующем пространству имен. Для автономного пространства имен DFS метаданные хранятся в реестре корневого сервера.

DFS Metadata cache

Кэш метаданных DFS — копия метаданных DFS в оперативной памяти, хранящаяся в Dfssvc.exe на корневых серверах.

Domain-based root referral cache and site caches

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

Драйвер службы SMB. В архитектуре DFS служит для передачи запросов от клиентов DFS к драйверу Dfs.sys.

Менеджер ввода-вывода отвечает за обработку операций с файлами при перенаправлении UNC-путей в Mup.sys. Является частью ядра ядра (Ntoskrnl.exe) операционной системы.

Mup (multiple UNC provider) в переводе означает множественный поставщик путей UNC. Mup.sys является сетевым драйвером, который обрабатывает запросы ввода-вывода (I/O) для файла или устройства, доступного по пути UNC. Если UNC путь является ссылкой DFS, Mup.sys разрешает его в физический путь UNC. После разрешения пути Mup.sys выбирает локальный перенаправитель, который будет обрабатывать путь UNC.

Для реализации службы предоставления общего доступа в Windows используется протокол CIFS (Common Internet File System). Перенаправитель Mrxsmb.sys обеспечивает взаимодействие между корневыми серверами, контроллерами домена и файловыми серверами Windows, использующими протокол CIFS.

Nwrdr.sys и Mrxdav.sys

Перенаправители для Netware и Web Distributed Authoring and Versioning (WebDAV), соответственно.

Workstation service (Wkssvc.dll)

Передает информацию о контроллере домена и доменном имени в Mup.sys. Эту информацию Mup.sys использует для создания ссылок в доменном кэше клиента. Также Workstation service является компонентом клиента SMB и обеспечивает управление Mrxsmb.sys.

Сетевой поставщик Windows. Служит для создания и поддержки клиентских сетевых подключений к удаленным файловым ресурсам.

Кэш ссылок, хранит ссылки, полученные клиентом при обращении к пространству имен. Кэш ссылок (также известный как кэш PKT) поддерживается в Mup.sys.

Доменный кэш содержит ссылки на доменные имена и ссылки на контроллеры домена, которые хранятся в памяти на каждом клиентском компьютере. В кэше домена хранятся NetBIOS-и DNS-доменные имена для локального домена, все доверенные домены в лесу, домены в доверенных лесах и сопоставления доменных имен с контроллерами домена. Домен кэша (SPC кэш) также хранится в Mup.sys.

Основные инструменты для администрирования пространства имен DFS. Сюда входит графическая оснастка Dfsgui.msc, утилита командной строки Dfscmd.exe и утилита Dfsutil.exe, используемая для выполнения расширенных задач DFS.

Содержит API NetDFSxxx, используемые для администрирования удаленных корневых серверов. Также содержит API, используемые для просмотра и очистки кэша ссылок (кэш PKT), кэша домена (кэш SPC) и кэша MUP на клиентах.

Физические структуры DFS и кэши

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

Корневые сервера

Физические структуры и кэши на корневом сервере различаются в зависимости от типа пространства имен, в котором размещается корневой сервер (доменный или автономный). Серверы под управлением Windows Server могут содержать несколько автономных и доменных корней.

На следующем рисунке показаны физическая структура и кэш DFS на корневых серверах.

физическая структура DFS и кэш корневого сервера

Stand-Alone DFS Metadata in the Registry (Автономные метаданные DFS в реестре)

Автономные метаданные DFS содержат информацию о корне, корневой цели, ссылках, целевых объектах ссылок и параметрах, определенных для каждого автономного пространства имен. Эти метаданные хранятся в реестре корневого сервера по адресу HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Dfs\Roots\Standalone.

Корневые серверы доменного пространства имен имеют запись реестра для каждого корня в разделе KEY_LOCAL_MACHINE\SOFTWARE\Microsoft\DFS\Roots\Domain, но эти записи не содержат метаданных DFS на основе домена. При запуске службы DFS на корневом сервере служба проверяет этот путь на наличие записей реестра, соответствующих корням домена. Если эти записи существуют, корневой сервер опрашивает контролллер домена с ролью эмулятора PDC, чтобы получить метаданные DFS для каждого доменного пространства имен и сохраняет эти метаданные в памяти.

DFS Registry Entries (Записи реестра DFS)

DFS поддерживает несколько записей реестра для настройки поведения DFS на корневых серверах. Записи реестра службы DFS находятся в реестре в следующих подразделах:

Root and Link Folders (Корень и папки ссылок)

Каждый корень и ссылка в пространстве имен имеют физическое представление на томе NTFS на каждом корневом сервере, на котором размещается это пространство имен. Корень DFS соответствует общей папке, известной как корневая папка (Root Folder) на корневом сервере. При использовании инструментов DFS для добавления ссылок в корневой каталог DFS создает специальные папки под каждой корневой папкой. Эти папки, называемые папками ссылок (Link Folders), на самом деле являются точками повторного анализа, и если вы попытаетесь получить к ним доступ на локальном сервере, то получите сообщение об ошибке. Клиенты DFS, которые получают доступ к папкам ссылок по всей сети, перенаправляются на соответствующий целевой объект.

Корень и ссылки на корневом сервере

DFS Metadata Cache (Кэш метаданных DFS)

Кэш метаданных DFS на корневых серверах содержит информацию о корне, корневых целевых объектах, ссылках, целевых объектах ссылок и параметрах, определенных в пространстве имен. Для доменных пространств имен эти метаданные  хранятся в объекте DFS в Active Directory, для автономных — в реестре корневого сервера.

Этот кэш хранится в оперативной памяти и обновляется каждый раз, когда корневой сервер опрашивает объект DFS в Active Directory (для доменных пространств имен) или реестр (для автономных пространств имен).

Domain-based Root Referral Cache (Корневой реферальный кэш на основе домена)

Когда клиент обращается к доменному корневому серверу напрямую, по адресу \\ServerName\RootName, корневой сервер предоставляет клиенту список корневых объектов домена (Domain-based Root Referral) для данного пространства имен.

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

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

Дополнительно:  Syoss root retoucher темно каштановый купить

Client Site Cache (Кэш сайта клиента)

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

По умолчанию DFS может хранить 200 000 записей в кэше клиентского сайта. Это ограничение определяется записью реестра MaxClientsToCache.

Target Site Cache (Кэш целевого сайта)

По умолчанию корневые серверы хранят записи в кэше целевого сайта до 24 часов. Этот интервал определяется значением записи реестра SiteSupportIntervalInSeconds (12 часов) на корневом сервере, умноженным на два. После заданного интервала времени DFS обновляет информацию о сайте в этом кэше. Если имя сайта изменяется или целевой сервер ссылок перемещается с одного сайта на другой, информация о сайте в этом кэше будет устаревать максимум в два раза больше значения записи реестра SiteSupportIntervalInSeconds (24 часа) или до тех пор, пока служба DFS не будет перезапущена.

Site Cost Cache (Кэш стоимости сайта)

В Active Directory есть понятие связи сайтов (site links), которое представляет из себя логическую связь двух или более сайтов, соответствующую физическим каналам связи между сайтами. У каждой связи есть своя стоимость (cost), которая определяет пропускную способность канала связи и, соответственно, затраты на передачу данных между сайтами. Эта информация используется при репликации Active Directory для определения наилучшего маршрута.

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

Служба DFS получает информацию о стоимости сайта для целевых объектов ссылок по мере необходимости, при выполнении запросов на направление клиентов. По умолчанию корневые серверы хранят записи в кэше стоимости сайта до 12 часов. Этот период определяется значением записи реестра SiteSupportIntervalInSeconds (12 часов) на корневом сервере. Если в Active Directory изменена стоимость связи между двумя сайтами, информация о стоимости сайта в этом кэше будет устаревать максимум в течение записи реестра SiteSupportIntervalInSeconds (12 часов) или до тех пор, пока служба DFS не будет перезапущена.

Запись реестра QuerySiteCostTimeoutinSeconds на корневых серверах также используется для этого кэша, чтобы указать период ожидания для запросов стоимости сайта. По истечении периода ожидания запрос информации о стоимости сайта в Active Directory завершится ошибкой. По умолчанию тайм-аут составляет 30 секунд. Если DFS не может определить стоимость целевого сайта в течение 30 секунд, принимается максимально возможная стоимость для целевого сервера.

Контроллеры домена

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

физическая структура DFS и кэш домен контроллера

DFS Object in Active Directory

Объект DFS в Active Directory хранит метаданные DFS для доменного пространства имен. Объект DFS создается при создании корневого каталога домена и Active Directory реплицирует весь объект DFS на все контроллеры домена в домене. Когда клиент запрашивает ссылку для доменного пространства имен, контроллер домена сначала проверяет свой доменный корневой кэш ссылок (описанный далее в этом разделе) на наличие существующей ссылки. Если таковой не существует, контроллер домена находит объект DFS для этого пространства имен и использует метаданные в объекте для создания ссылки.

На следующем рисунке показано расположение объектов DFS в Active Directory. Каждый объект DFS (FTDFS object) соответствует доменному пространству имен.

объект DFS в Active Directory

Каждый объект DFS имеет следующие четыре важных атрибута:

pKT — двоичное представление метаданных DFS для этого корня.
• pKTGuid — лобальный уникальный идентификатор (GUID) метаданных DFS.
remoteServerName — перечисляет корневые целевые объекты для корня.
• Security descriptor — дескриптор безопасности, контролирует доступ и определяет, кому разрешено изменять объект DFS.

По поводу размера объекта DFS. При записи метаданных используется приблизительно 400 байт на одну ссылку DFS. Любое изменение пространства имен приводит к тому, что весь объект DFS реплицируется на все контроллеры домена в домене. Для снижения сетевого трафика, возникающего при изменении в пространстве имен, рекомендуется объект DFS для доменного пространства имен ограничить размером в 5МБ (приблизительно 5000 ссылок).

DFS Registry Entries (Записи реестра DFS)

DFS поддерживает несколько записей реестра для настройки поведения DFS на контроллерах домена. Записи реестра DFS находятся в реестре в следующих подразделах:

Domain Name Referral Cache (Кэш ссылок доменных имен)

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

По умолчанию контроллеры домена хранят ссылки на доменные имена в кэше памяти в течение 12 часов; этот период определяется записью реестра DomainNameIntervalinSeconds на контроллере домена. Перезапуск службы DFS на контроллере домена приведет к очистке этого кэша. Если доменное имя изменяется или домены добавляются или удаляются из леса или доверенных лесов, эти изменения отражаются в ссылках на доменные имена через 12 часов или после очистки этого кэша.

Domain Controller Referral Cache (Кэш ссылок контроллера домена)

Ссылка на контроллер домена содержит NetBIOS и DNS-имена контроллеров домена для списка доменов, которые он кэшировал. Клиент DFS запрашивает ссылку на контроллер домена у контроллера домена 🙂 чтобы определить, какие контроллеры домена могут предоставить ссылку для доменного пространства имен.

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

Domain-based Root Referral Cache (Корневой реферальный кэш на основе домена)

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

По умолчанию контроллеры домена хранят корневые ссылки на основе домена в кэше памяти в течение 15 минут; этот период определяется записью реестра RootReferralTimeoutInSeconds на контроллере домена. Перезапуск службы DFS на контроллере домена приведет к очистке этого кэша. Если корневые целевые объекты добавляются или удаляются, или если в корне изменяются настройки, эти изменения отражаются в доменных корневых ссылках через 15 минут или после очистки этого кэша.

Client Site Cache (Кэш сайта клиента)

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

По умолчанию DFS может хранить 200 000 записей в кэше клиентского сайта. Это ограничение определяется записью реестра MaxClientsToCache.

Target Site Cache (Кэш целевого сайта)

По умолчанию контроллеры домена хранят записи в кэше целевого сайта до 24 часов. Этот интервал определяется значением записи реестра SiteSupportIntervalInSeconds (12 часов) на контроллере домена, умноженным на два. После заданного интервала времени DFS обновляет информацию о сайте в этом кэше. Если имя сайта изменяется или корневой целевой объект перемещается с одного сайта на другой, информация о сайте в этом кэше будет устаревать максимум в два раза больше значения записи реестра SiteSupportIntervalInSeconds (24 часа) или до тех пор, пока служба DFS не будет перезапущена на контроллере домена.

Site Cost Cache (Кэш стоимости сайта)

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

Служба DFS получает сведения о стоимости сайта для контроллеров домена и корневых целевых объектов на базе домена, необходимые для выполнения запросов на направление клиентов. По умолчанию записи в кэше затрат сайта сохраняются в течение 12 часов. Этот период определяется значением записи реестра SiteSupportIntervalInSeconds (12 часов) на локальном контроллере домена. Если в Active Directory изменена стоимость подключения между двумя сайтами, информация о стоимости сайта в этом кэше будет устаревать максимум в течение записи реестра SiteSupportIntervalInSeconds (12 часов) или до тех пор, пока служба DFS не будет перезапущена.

Запись реестра QuerySiteCostTimeoutinSeconds на контроллерах домена также используется для этого кэша, чтобы указать период ожидания для запросов стоимости сайта. По истечении периода ожидания запрос стоимости сайта в Active Directory завершится ошибкой. По умолчанию тайм-аут составляет 30 секунд. Если DFS не может определить стоимость сайта в течение 30 секунд, DFS принимает максимально возможную стоимость для этого сайта.

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

На следующем рисунке показаны физические структуры и кэши на клиентах DFS.

физическая структура DFS и кэш клиента

DFS Registry Entries (Записи реестра DFS)

Записи реестра DFS находятся в реестре клиента DFS в следующих разделах:

Domain cache (Кэш домена на клиентах)

Кэш домена на клиентах содержит два типа ссылок:

• Ссылки на доменные имена — доменные имена NetBIOS и DNS для локального домена клиента, доверенные домены в лесу и домены в доверенных лесах.
• Ссылки на контроллеры домена — сопоставления доменных имен с контроллерами домена, на которых размещены эти домены.

Просмотреть содержимое доменного кэша на клиентском компьютере из командной строки можно с помощью команды Dfsutil /spcinfo.

содержимое доменного кэша DFS

Данный пример вывода может быть интерпретирован следующим образом:

MUP Cache  (Кэш MUP)

Кэш множественного поставщика путей UNC (MUP) хранит информацию о том, какой перенаправитель (напр. DFS, SMB или WebDAV) требуется для каждого пути UNC, к которому клиентский компьютер пытается получить доступ. Записи в кэше MUP хранятся в течение 15 минут. Для очистки этого кэша можно использовать команду Dfsutil /PurgeMupCache. Это может потребоваться при изменении типа папки, например из общей папки SMB в корневую папку WebDAV или DFS, или наоборот.

Referral Cache  (Кэш ссылок на клиентах)

Клиенты DFS хранят корневые рефералы и ссылки на рефералы в кэше рефералов, также называемом кэшем PKT. Эти ссылки позволяют клиентам получить доступ к корневому каталогу и ссылкам в пространстве имен. Вы можете просмотреть содержимое реферального кэша на клиенте с помощью команды Dfsutil /pktinfo.

кэш ссылок на клиенте

На рисунке показаны четыре типа рефералов:

(1) рефералы NETLOGON и SYSVOL;
(2) доменные корневые рефералы;
(3) автономные корневые рефералы;
(4) ссылочные рефералы.

Каждый из этих рефералов содержит следующую информацию:

Entry and ShortEntry 

Entry указывает полное имя, ShortEntry задает краткое имя (восемь символов, за которыми следует точка и еще три символа) пути. Корневые серверы и контроллеры домена под управлением Windows Server используют полное имя при заполнении Entry и ShortEntry.

Expires in seconds

Указывает время жизни реферала. Ноль (0) секунд означает, что срок действия ссылки истек и что клиент получит новую ссылку при следующей попытке доступа к целевому серверу.

UseCount and Type

Количество и тип пользователей. UseCount — количество открытых соединений и файлов для этого пути. Если клиент имеет подключенный диск к пути DFS, то количество его использования увеличивается на 1.  Type указывает тип реферала. Некоторые распространенные типы включают в себя:

Type 0x81 (REFERRAL_SVC DFS) — указывает на корневую ссылку.
Type 0x1 (DFS) — указывает на ссылку-реферал, которая имеет физические общие папки в качестве целевых объектов ссылок.
Type 0x10 (OUTSIDE_MY_DOM) — указывает на ссылку-реферал, целью которой является путь в доменном пространстве имен.

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

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

Оцените статью
Master Hi-technology
Добавить комментарий