Масштабируйте кластер Service Fabric тип узла, который не является основным

Эта статья описывает, как масштабировать кластер Service Fabric для узлов неосновного типа с минимальными простоем. Обновления SKU на месте не поддерживаются на узлах кластера Service Fabric, так как такие операции могут привести к потере данных и доступности. Самый безопасный, самый надежный и рекомендуемый метод масштабирования типа узла Service Fabric — это:

Add a new node type to your Service Fabric cluster, backed by your upgraded (or modified) virtual machine scale set SKU and configuration. This step also involves setting up a new load balancer, subnet, and public IP for the scale set.
Когда как оригинальные, так и обновленные наборы масштабов работают параллельно, перенесите рабочую нагрузку, установив ограничения на размещение приложений на новом типе узла.
Убедитесь, что кластер находится в рабочем состоянии, затем удалите исходный набор масштабирования (и связанные ресурсы), а также состояние узлов для удаленных узлов.

Представленный процесс ознакомит вас с обновлением размера виртуальной машины и операционной системы виртуальных машин некритичного типa узлов в образцовом кластере с серебряной устойчивостью. Кластер поддерживается единственным набором масштабирования с пятью узлами, используемым как вторичный тип узла. Тип узла по умолчанию с системными службами Service Fabric останется нетронутым. Мы будем модернизировать тип узла, который не является основным.

From VM size Standard_D2_V2 to Standard D4_V2, and
Из операционной системы виртуальной машины Windows Server 2019 Datacenter в Windows Server 2022 Datacenter.

Предупреждение

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

Не пытайтесь выполнять процедуру увеличения масштаба узлов вторичного типа, если состояние кластера нездоровое, так как это только еще больше дестабилизирует кластер. Мы воспользуемся пошаговыми шаблонами развертывания Azure, использованными в руководстве Масштабирование основного узла кластера Service Fabric. However, we'll modify them so they aren't specific to primary node types. Шаблоны доступны на GitHub.

Настройка тестового кластера

Давайте настроим начальный тестовый кластер Service Fabric. Сначала скачайте примеры шаблонов Azure Resource Manager, которые мы будем использовать для выполнения этого сценария.

Затем войдите в учетную запись Azure.

# Sign in to your Azure account
Login-AzAccount -SubscriptionId "<subscription ID>"

Затем откройте файлparameters.json и обновите значение для clusterName на уникальное значение (в Azure).

Следующие команды помогут вам создать новый самозаверяющий сертификат и развернуть тестовый кластер. Если у вас уже есть сертификат, который вы хотите использовать, перейдите к разделу "Использовать существующий сертификат для развертывания кластера".

Создание самозаверяющего сертификата и развертывание кластера

First, assign the variables you'll need for Service Fabric cluster deployment. Настройте значения для resourceGroupName, и certSubjectNameparameterFilePathtemplateFilePath для конкретной учетной записи и среды:

# Assign deployment variables
$resourceGroupName = "sftestupgradegroup"
$certOutputFolder = "c:\certificates"
$certPassword = "Password!1" | ConvertTo-SecureString -AsPlainText -Force
$certSubjectName = "sftestupgrade.southcentralus.cloudapp.azure.com"
$parameterFilePath = "C:\parameters.json"
$templateFilePath = "C:\Initial-TestClusterSetup.json"

Примечание.

Ensure that the certOutputFolder location exists on your local machine before running the command to deploy a new Service Fabric cluster. Затем разверните тестовый кластер Service Fabric:

# Deploy the initial test cluster
New-AzServiceFabricCluster `
    -ResourceGroupName $resourceGroupName `
    -CertificateOutputFolder $certOutputFolder `
    -CertificatePassword $certPassword `
    -CertificateSubjectName $certSubjectName `
    -TemplateFile $templateFilePath `
    -ParameterFile $parameterFilePath

После завершения развертывания найдите PFX-файл ($certPfx) на локальном компьютере и импортируйте его в хранилище сертификатов:

cd c:\certificates
$certPfx = ".\sftestupgradegroup20200312121003.pfx"
Import-PfxCertificate `
     -FilePath $certPfx `
     -CertStoreLocation Cert:\CurrentUser\My `
     -Password (ConvertTo-SecureString Password!1 -AsPlainText -Force)

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

Использование существующего сертификата для развертывания кластера

Кроме того, для развертывания тестового кластера можно использовать существующий сертификат Azure Key Vault. Для этого вам нужно будет obtain references to your Key Vault и отпечаток сертификата.

# Key Vault variables
$certUrlValue = "https://sftestupgradegroup.vault.azure.net/secrets/sftestupgradegroup20200309235308/dac0e7b7f9d4414984ccaa72bfb2ea39"
$sourceVaultValue = "/subscriptions/########-####-####-####-############/resourceGroups/sftestupgradegroup/providers/Microsoft.KeyVault/vaults/sftestupgradegroup"
$thumb = "AA11BB22CC33DD44EE55FF66AA77BB88CC99DD00"

Затем укажите имя группы ресурсов для кластера и задайте расположения templateFilePath и parameterFilePath.

Примечание.

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

$resourceGroupName = "sftestupgradegroup"
$templateFilePath = "C:\Initial-TestClusterSetup.json"
$parameterFilePath = "C:\parameters.json"

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

# Deploy the initial test cluster
New-AzResourceGroupDeployment `
    -ResourceGroupName $resourceGroupName `
    -TemplateFile $templateFilePath `
    -TemplateParameterFile $parameterFilePath `
    -CertificateThumbprint $thumb `
    -CertificateUrlValue $certUrlValue `
    -SourceVaultValue $sourceVaultValue `
    -Verbose

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

Подключитесь к кластеру и убедитесь, что все пять его узлов работоспособны (замените clusterNamethumb переменные собственными значениями):

# Connect to the cluster
$clusterName = "sftestupgrade.southcentralus.cloudapp.azure.com:19000"
$thumb = "AA11BB22CC33DD44EE55FF66AA77BB88CC99DD00"
Connect-ServiceFabricCluster `
    -ConnectionEndpoint $clusterName `
    -KeepAliveIntervalInSec 10 `
    -X509Credential `
    -ServerCertThumbprint $thumb  `
    -FindType FindByThumbprint `
    -FindValue $thumb `
    -StoreLocation CurrentUser `
    -StoreName My
# Check cluster health
Get-ServiceFabricClusterHealth

С этим мы готовы начать процедуру обновления.

Deploy a new non-primary node type with an upgraded scale set

Чтобы обновить (вертикально масштабировать) тип узла, сначала необходимо развернуть новый тип узла, поддерживаемый новым масштабируемым набором и вспомогательными ресурсами. Новый набор масштабирования будет отмечен как не основной (isPrimary: false), так же как и оригинальный набор масштабирования. Если вы хотите увеличить тип первичного узла, см. Масштабирование типа первичного узла кластера Service Fabric. The resources created in the following section will ultimately become the new node type in your cluster, and the original node type resources will be deleted.

Обновите шаблон кластера вместе с обновленным набором масштаба

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

Большинство необходимых изменений для этого шага уже внесены для вас в файл шаблона Step1-AddPrimaryNodeType.json. However, an additional change must be made so the template file works for non-primary node types. Следующие разделы подробно объяснят эти изменения, и будет указано, когда необходимо внести изменения.

Примечание.

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

Создание новой подсети в существующей виртуальной сети

{
    "name": "[variables('subnet1Name')]",
    "properties": {
        "addressPrefix": "[variables('subnet1Prefix')]"
    }
}

Создайте новый публичный IP-адрес с уникальной меткой домена.

{
    "apiVersion": "[variables('publicIPApiVersion')]",
    "type": "Microsoft.Network/publicIPAddresses",
    "name": "[concat(variables('lbIPName'),'-',variables('vmNodeType1Name'))]",
    "location": "[variables('computeLocation')]",
    "properties": {
        "dnsSettings": {
            "domainNameLabel": "[concat(variables('dnsName'),'-','nt1')]"
        },
        "publicIPAllocationMethod": "Dynamic"
    },
    "tags": {
        "resourceType": "Service Fabric",
        "clusterName": "[parameters('clusterName')]"
    }
}

Создание подсистемы балансировки нагрузки для общедоступного IP-адреса

"dependsOn": [
    "[concat('Microsoft.Network/publicIPAddresses/',concat(variables('lbIPName'),'-',variables('vmNodeType1Name')))]"
]

Создание нового масштабируемого набора виртуальных машин (с обновленными SKU виртуальных машин и ОС)

Node Type Ref

"nodeTypeRef": "[variables('vmNodeType1Name')]"

VM SKU

"sku": {
    "name": "[parameters('vmNodeType1Size')]",
    "capacity": "[parameters('nt1InstanceCount')]",
    "tier": "Standard"
}

OS SKU

"imageReference": {
    "publisher": "[parameters('vmImagePublisher1')]",
    "offer": "[parameters('vmImageOffer1')]",
    "sku": "[parameters('vmImageSku1')]",
    "version": "[parameters('vmImageVersion1')]"
}

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

Add a new non-primary node type to the cluster

Теперь, когда новый тип узла (vmNodeType1Name) имеет собственное имя, подсеть, IP, балансировщик нагрузки и набор масштабирования, он может повторно использовать все остальные переменные из оригинального типа узла (такие как nt0applicationEndPort, nt0applicationStartPort, и nt0fabricTcpGatewayPort).

В существующем шаблонном файле параметр isPrimary установлен на true для руководства Масштабирование типа основных узлов кластера Service Fabric. Измените isPrimary на false для вашего типа узла, который не является основным.

"name": "[variables('vmNodeType1Name')]",
"applicationPorts": {
    "endPort": "[variables('nt0applicationEndPort')]",
    "startPort": "[variables('nt0applicationStartPort')]"
},
"clientConnectionEndpointPort": "[variables('nt0fabricTcpGatewayPort')]",
"durabilityLevel": "Bronze",
"ephemeralPorts": {
    "endPort": "[variables('nt0ephemeralEndPort')]",
    "startPort": "[variables('nt0ephemeralStartPort')]"
},
"httpGatewayEndpointPort": "[variables('nt0fabricHttpGatewayPort')]",
"isPrimary": false,
"reverseProxyEndpointPort": "[variables('nt0reverseProxyEndpointPort')]",
"vmInstanceCount": "[parameters('nt1InstanceCount')]"

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

Obtain your Key Vault references

To deploy the updated configuration, you'll need several references to the cluster certificate stored in your Key Vault. Самый простой способ найти эти значения — на портале Azure. Вам потребуется:

URL-адрес хранилища ключей сертификата кластера. На портале Azure в Key Vault выберите "Сертификаты>", чтобы выбрать нужный> сертификата:
```
$certUrlValue="https://sftestupgradegroup.vault.azure.net/secrets/sftestupgradegroup20200309235308/dac0e7b7f9d4414984ccaa72bfb2ea39"
```
Отпечаток сертификата вашего кластера. (Вероятно, у вас это уже есть, если вы подключились к первоначальному кластеру, чтобы проверить его состояние.) Из того же раздела сертификатов (Сертификаты>Ваш желаемый сертификат) в портале Azure, скопируйте X.509 SHA-1 отпечаток сертификата (в шестнадцатеричном виде):
```
$thumb = "AA11BB22CC33DD44EE55FF66AA77BB88CC99DD00"
```
Идентификатор ресурса хранилища ключей. На портале Azure в Key Vault выберите свойства>идентификатор ресурса:
```
$sourceVaultValue = "/subscriptions/########-####-####-####-############/resourceGroups/sftestupgradegroup/providers/Microsoft.KeyVault/vaults/sftestupgradegroup"
```

Развертывание обновленного шаблона

Настройте templateFilePath по мере необходимости и выполните следующую команду:

# Deploy the new node type and its resources
$templateFilePath = "C:\Step1-AddPrimaryNodeType.json"
New-AzResourceGroupDeployment `
    -ResourceGroupName $resourceGroupName `
    -TemplateFile $templateFilePath `
    -TemplateParameterFile $parameterFilePath `
    -CertificateThumbprint $thumb `
    -CertificateUrlValue $certUrlValue `
    -SourceVaultValue $sourceVaultValue `
    -Verbose

После завершения развертывания проверьте работоспособность кластера и убедитесь, что все узлы обоих типов узлов работоспособны.

Get-ServiceFabricClusterHealth

Перенесите рабочие нагрузки на новый тип узла.

Подождите, пока все приложения не будут перемещены на новый тип узла и станут здоровыми.

Disable the nodes in the original node type scale set

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

# Disable the nodes in the original scale set.
$nodeType = "nt0vm"
$nodes = Get-ServiceFabricNode
Write-Host "Disabling nodes..."
foreach($node in $nodes)
{
  if ($node.NodeType -eq $nodeType)
  {
    $node.NodeName
    Disable-ServiceFabricNode -Intent RemoveNode -NodeName $node.NodeName -Force
  }
}

Use Service Fabric Explorer to monitor the progression of nodes in the original scale set from Disabling to Disabled status. Дождитесь, пока все узлы не будут в состоянии Отключено.

Остановка данных на отключенных узлах

Теперь можно остановить данные на отключенных узлах.

# Stop data on the disabled nodes.
foreach($node in $nodes)
{
  if ($node.NodeType -eq $nodeType)
  {
    $node.NodeName
    Start-ServiceFabricNodeTransition -Stop -OperationId (New-Guid) -NodeInstanceId $node.NodeInstanceId -NodeName $node.NodeName -StopDurationInSeconds 10000
  }
}

Remove the original node type and clean up its resources

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

Remove the original scale set

First remove the node type's backing scale set.

$scaleSetName = "nt0vm"
$scaleSetResourceType = "Microsoft.Compute/virtualMachineScaleSets"
Remove-AzResource -ResourceName $scaleSetName -ResourceType $scaleSetResourceType -ResourceGroupName $resourceGroupName -Force

Удалите исходные ресурсы IP-адресов и балансировщика нагрузки.

Теперь вы можете удалить исходный IP-адрес и ресурсы подсистемы балансировки нагрузки. На этом этапе вы также обновите имя DNS.

Примечание.

Этот шаг необязателен, если вы уже используете общедоступный IP-адрес SKU уровня "Стандартный" и балансировщик нагрузки. В этом случае может быть несколько масштабируемых наборов или типов узлов в одном балансировщике нагрузки. Выполните следующие команды, изменив $lbname значение по мере необходимости.

# Delete the original IP and load balancer resources
$lbName = "LB-sftestupgrade-nt0vm"
$lbResourceType = "Microsoft.Network/loadBalancers"
$ipResourceType = "Microsoft.Network/publicIPAddresses"
$oldPublicIpName = "PublicIP-LB-FE-nt0vm"
$newPublicIpName = "PublicIP-LB-FE-nt1vm"
$oldPublicIP = Get-AzPublicIpAddress -Name $oldPublicIpName  -ResourceGroupName $resourceGroupName
$nonPrimaryDNSName = $oldNonPrimaryPublicIP.DnsSettings.DomainNameLabel
$nonPrimaryDNSFqdn = $oldNonPrimaryPublicIP.DnsSettings.Fqdn
Remove-AzResource -ResourceName $lbName -ResourceType $lbResourceType -ResourceGroupName $resourceGroupName -Force
Remove-AzResource -ResourceName $oldPublicIpName -ResourceType $ipResourceType -ResourceGroupName $resourceGroupName -Force
$PublicIP = Get-AzPublicIpAddress -Name $newPublicIpName  -ResourceGroupName $resourceGroupName
$PublicIP.DnsSettings.DomainNameLabel = $nonPrimaryDNSName
$PublicIP.DnsSettings.Fqdn = $nonPrimaryDNSFqdn
Set-AzPublicIpAddress -PublicIpAddress $PublicIP

Remove node state from the original node type

The original node type nodes will now show Error for their Health State. Удалите состояние их узла из кластера.

# Remove state of the obsolete nodes from the cluster
$nodeType = "nt0vm"
$nodes = Get-ServiceFabricNode
Write-Host "Removing node state..."
foreach($node in $nodes)
{
  if ($node.NodeType -eq $nodeType)
  {
    $node.NodeName
    Remove-ServiceFabricNodeState -NodeName $node.NodeName -Force
  }
}

Теперь Service Fabric Explorer должен отражать только пять узлов нового типа узла (nt1vm), все с значениями состояния работоспособности ОК. Мы исправим следующее, обновив шаблон, чтобы отразить последние изменения и повторное развертывание.

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

Большинство необходимых изменений для этого шага уже внесено для вас в шаблонный файл Step3-CleanupOriginalPrimaryNodeType.json. Однако необходимо внести дополнительное изменение, чтобы файл шаблона работал для типов узлов, отличных от первичных. The following sections will explain these changes in detail, and call outs will be made when you must make a change.

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

Обновите кластер managementEndpoint в шаблоне развертывания, чтобы ссылаться на новый IP-адрес (обновив vmNodeType0Name с vmNodeType1Name).

  "managementEndpoint": "[concat('https://',reference(concat(variables('lbIPName'),'-',variables('vmNodeType1Name'))).dnsSettings.fqdn,':',variables('nt0fabricHttpGatewayPort'))]",

Удаление ссылки на исходный тип узла

Удалите ссылку на исходный тип узла из ресурса Service Fabric в шаблоне развертывания.

В существующем файле шаблона параметр isPrimary установлен на true в руководстве Изменение масштаба типа первичной узловой точки кластера Service Fabric. Change isPrimary to false for your non-primary node type:

"name": "[variables('vmNodeType0Name')]",
"applicationPorts": {
    "endPort": "[variables('nt0applicationEndPort')]",
    "startPort": "[variables('nt0applicationStartPort')]"
},
"clientConnectionEndpointPort": "[variables('nt0fabricTcpGatewayPort')]",
"durabilityLevel": "Bronze",
"ephemeralPorts": {
    "endPort": "[variables('nt0ephemeralEndPort')]",
    "startPort": "[variables('nt0ephemeralStartPort')]"
},
"httpGatewayEndpointPort": "[variables('nt0fabricHttpGatewayPort')]",
"isPrimary": false,
"reverseProxyEndpointPort": "[variables('nt0reverseProxyEndpointPort')]",
"vmInstanceCount": "[parameters('nt0InstanceCount')]"

Настройте политики здоровья для игнорирования существующих ошибок

Только для кластеров Silver и более высокого уровня устойчивости обновите ресурс кластера в шаблоне и настройте политики работоспособности, чтобы игнорировать fabric:/System состояние приложений, добавив applicationDeltaHealthPolicies в свойства ресурсов кластера, как указано ниже. Следующая политика будет игнорировать существующие ошибки, но не разрешать новые ошибки, связанные со здоровьем.

"upgradeDescription":  
{ 
 "forceRestart": false, 
 "upgradeReplicaSetCheckTimeout": "10675199.02:48:05.4775807", 
 "healthCheckWaitDuration": "00:05:00", 
 "healthCheckStableDuration": "00:05:00", 
 "healthCheckRetryTimeout": "00:45:00", 
 "upgradeTimeout": "12:00:00", 
 "upgradeDomainTimeout": "02:00:00", 
 "healthPolicy": { 
   "maxPercentUnhealthyNodes": 100, 
   "maxPercentUnhealthyApplications": 100 
 }, 
 "deltaHealthPolicy":  
 { 
   "maxPercentDeltaUnhealthyNodes": 0, 
   "maxPercentUpgradeDomainDeltaUnhealthyNodes": 0, 
   "maxPercentDeltaUnhealthyApplications": 0, 
   "applicationDeltaHealthPolicies":  
   { 
       "fabric:/System":  
       { 
           "defaultServiceTypeDeltaHealthPolicy":  
           { 
                   "maxPercentDeltaUnhealthyServices": 0 
           } 
       } 
   } 
 } 
}

Удаление вспомогательных ресурсов для исходного типа узла

Удалите все остальные ресурсы, связанные с исходным типом узла из шаблона ARM и файла параметров. Удалите следующее:

    "vmImagePublisher": {
      "value": "MicrosoftWindowsServer"
    },
    "vmImageOffer": {
      "value": "WindowsServer"
    },
    "vmImageSku": {
      "value": "2019-Datacenter"
    },
    "vmImageVersion": {
      "value": "latest"
    },

Развертывание завершенного шаблона

Наконец, разверните измененный шаблон Azure Resource Manager.

# Deploy the updated template file
$templateFilePath = "C:\Step3-CleanupOriginalPrimaryNodeType"
New-AzResourceGroupDeployment `
    -ResourceGroupName $resourceGroupName `
    -TemplateFile $templateFilePath `
    -TemplateParameterFile $parameterFilePath `
    -CertificateThumbprint $thumb `
    -CertificateUrlValue $certUrlValue `
    -SourceVaultValue $sourceVaultValue `
    -Verbose

Примечание.

Этот шаг займет некоторое время, как правило, до двух часов. Обновление изменит параметры на InfrastructureService; следовательно, требуется перезагрузка узла. В этом случае forceRestart игнорируется. upgradeReplicaSetCheckTimeout Параметр указывает максимальное время, когда Service Fabric ожидает, чтобы секция была в безопасном состоянии, если она еще не в безопасном состоянии. Once safety checks pass for all partitions on a node, Service Fabric proceeds with the upgrade on that node. Значение параметра upgradeTimeout может быть сокращено до 6 часов, но для максимальной безопасности следует использовать 12 часов.

После завершения развертывания убедитесь, что состояние ресурса Service Fabric готово на портале Azure. Убедитесь, что вы можете получить доступ к новой конечной точке Service Fabric Explorer, состояние работоспособности кластера— ОК, и все развернутые приложения работают правильно.

С этим вы вертикально масштабировали кластер, не относящийся к первичному типу узла!

Дальнейшие действия

Узнайте, как добавить тип узла в кластер
Узнайте о масштабируемости приложений.
Масштабирование кластера Azure внутрь или наружу.
Программное масштабирование кластера Azure с помощью свободного пакета SDK для вычислений Azure.
Увеличить или уменьшить размер автономного кластера.

Обратная связь

Была ли эта страница полезна?

Last updated on 2025-04-22

Поделиться через

Масштабируйте кластер Service Fabric тип узла, который не является основным

Настройка тестового кластера

Создание самозаверяющего сертификата и развертывание кластера

Использование существующего сертификата для развертывания кластера

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

Deploy a new non-primary node type with an upgraded scale set

Обновите шаблон кластера вместе с обновленным набором масштаба

Создание новой подсети в существующей виртуальной сети

Создайте новый публичный IP-адрес с уникальной меткой домена.

Создание подсистемы балансировки нагрузки для общедоступного IP-адреса

Создание нового масштабируемого набора виртуальных машин (с обновленными SKU виртуальных машин и ОС)

Add a new non-primary node type to the cluster

Obtain your Key Vault references

Развертывание обновленного шаблона

Перенесите рабочие нагрузки на новый тип узла.

Disable the nodes in the original node type scale set

Остановка данных на отключенных узлах

Remove the original node type and clean up its resources

Remove the original scale set

Удалите исходные ресурсы IP-адресов и балансировщика нагрузки.

Remove node state from the original node type

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

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

Удаление ссылки на исходный тип узла

Настройте политики здоровья для игнорирования существующих ошибок

Удаление вспомогательных ресурсов для исходного типа узла

Развертывание завершенного шаблона

Дальнейшие действия

Обратная связь

Дополнительные ресурсы