Azure Monitor SCOM 관리되는 인스턴스 - 질문과 대답

대기 시간을 유지하려면 다른 Azure 리소스와 동일한 지역에 VNet을 두는 것이 좋습니다.

최소 주소 공간은 /27입니다. 즉, /28 이상은 작동하지 않습니다.

• VNet에는 두 개의 서브넷이 필요합니다.
  • SCOM 관리되는 인스턴스의 경우
  • SQL Managed Instance의 경우
• SQL Managed Instance의 서브넷은 위임된 전용 서브넷이 되며 SCOM 관리되는 인스턴스에서 사용되지 않습니다. SQL Managed Instance/SCOM 관리되는 인스턴스를 만드는 동안 나중에 혼동을 피하기 위해 적절하게 서브넷 이름을 지정합니다.

최소 주소 공간은 SQL MI 서브넷의 경우 /27, SCOM 관리되는 인스턴스 서브넷의 경우 /28이어야 합니다.

아니요. 두 옵션 모두 비워둘 수 있습니다.

아니요, 모두 사용하지 않도록 설정하거나 조직의 기본 설정에 따라 일부를 사용하도록 설정할 수 있습니다.

VNet이 여러 개 만들어진 경우 VNet을 피어링해야 합니다. 두 네트워크를 피어링하는 경우 두 네트워크에서 서로 피어링해야 합니다. 따라서 3개의 네트워크를 피어링하는 경우 6개의 피어링을 수행해야 합니다. 피어링에 대한 자세한 내용은 Azure Virtual Network 피어링을 참조하세요.

• 피어링 이름을 지정해야 합니다(피어링 링크 이름 필드에).
• 이름은 현재 네트워크에서 다른 네트워크까지의 피어 네트워크 이름을 지정하는 데 사용됩니다. 두 번째 이름은 다른 네트워크에서 이 네트워크로의 피어 네트워크 이름을 지정하는 데 사용됩니다.
• Virtual Network 섹션에서 피어링 중인 VNet의 이름을 지정합니다. VNet을 찾을 수 없는 경우 리소스 ID를 사용하여 검색할 수 있습니다. 나머지 옵션은 기본값으로 보존합니다.

1. 지역 목록에 선택하려는 지역(미국 서부 또는 서유럽)이 표시되지 않으면 지역이 표시되지 않음을 선택한 다음 구독 할당량 증가 요청을 선택합니다.
2. 기본 사항에 필수 필드를 입력하고 세부 정보로 이동하여 문제 세부 정보를 입력합니다.
3. 세부 정보 입력을 선택합니다. 오른쪽 창에 할당량 세부 정보 페이지가 열립니다. 지역에서 원하는 지역을 선택하고 제한을 원하는 대로 변경합니다(서브넷 10개와 vCore 500개면 충분함). 저장하고 계속을 선택한 후 다음: 검토 + 만들기 >>를 선택하여 티켓을 제출합니다. 티켓이 해결되는 데 24시간이 걸릴 수 있습니다. SQL MI 인스턴스 만들기를 진행하기 전에 문제가 해결될 때까지 기다립니다.
   자세한 내용은 어떤 Azure 지역이 지원되나요?를 참조하세요.

Azure RBAC는 Azure가 권한을 부여하는 동안 따르는 역할 기반 액세스 제어 시스템입니다. 자세한 내용은 Azure 역할 기반 액세스 제어를 참조하세요.
Azure RBAC는 Azure 역할과 Microsoft Entra ID 역할로 구분됩니다. 높은 수준에서 Azure 역할은 Azure 리소스를 관리하는 권한을 제어하는 ​​반면, Microsoft Entra ID 역할은 Microsoft Entra ID 디렉터리 리소스를 관리하는 권한을 제어합니다. 다음 표에서는 몇 가지 차이점을 비교합니다. |Azure 역할|Microsoft Entra ID 역할| |---|---| |Azure 리소스에 대한 액세스 관리|Microsoft Entra ID 리소스에 대한 액세스 관리| |사용자 지정 역할 지원|사용자 지정 역할 지원| |범위를 여러 수준(관리 그룹, 구독, 리소스 그룹, 리소스)에서 지정할 수 있음|범위를 테넌트 수준(조직 전체), 관리 장치 또는 개별 개체(예: 특정 애플리케이션)에서 지정할 수 있음| |역할 정보를 Azure Portal, Azure CLI, Azure PowerShell, Azure Resource Manager 템플릿, REST API에서 액세스할 수 있음|역할 정보를 Azure 관리 포털, Microsoft 365, 관리 센터, Microsoft Graph, Microsoft Entra ID PowerShell에서 액세스할 수 있음|
다음은 클래식 구독 관리자 역할, Azure 역할 및 Azure AD 역할이 어떻게 관련되어 있는지에 대한 개략적인 보기입니다.

전역 관리자 역할이 있는 사용자는 다음과 같이 Microsoft Entra ID ID를 사용하는 Microsoft Entra ID 및 서비스의 모든 관리 기능에 액세스할 수 있습니다.

• Microsoft 365 Defender 포털
• 규정 준수 포털
• Exchange Online
• SharePoint Online
• Skype for Business Online

배포 단계에서 SCOM 관리되는 인스턴스 배포 시 오류가 표시되는 데는 여러 가지 이유가 있을 수 있습니다. 만들기 중 잘못된 입력이나 일부 백 엔드 오류가 원인일 수 있습니다. 추가 지원이 필요한 경우 지원 티켓을 제출합니다. 배포 중 오류가 발생할 경우 인스턴스를 삭제하고 다시 만드는 것이 가장 좋습니다. 자세한 내용은 Azure Monitor SCOM 관리되는 인스턴스 문제 해결을 참조하세요.

인스턴스 보기 자체 또는 리소스 그룹 보기에서 인스턴스를 삭제할 수 있습니다.
인스턴스 보기의 상단 메뉴에서 삭제를 선택하고 인스턴스가 삭제되었다는 확인 메시지를 기다립니다. 또는 리소스 그룹 보기로 이동합니다. Azure Search 창에서 리소스 그룹을 검색하고 결과 목록에서 리소스 그룹을 엽니다. SCOM 관리되는 인스턴스가 있는 리소스 그룹으로 이동하여 인스턴스를 삭제합니다.
인스턴스가 삭제되면 SQL MI에서 만들어진 두 데이터베이스도 삭제해야 합니다. 리소스 보기에서 SCOM 관리되는 인스턴스에 지정한 이름에 따라 두 개의 데이터베이스를 선택하고 삭제를 선택합니다.

현재 지원되지 않습니다. 이제 System Center Operations Manager와 별도로 고객은 온-프레미스에서 실행되는 VM에 Arc 에이전트를 설치하고 Azure Portal에서 리소스를 볼 수 있습니다. Azure Portal에서 리소스를 보기 시작하면 해당 리소스에 대해 Azure 서비스를 사용할 수 있습니다(적절한 비용이 발생함).

SCOM 관리되는 인스턴스와 System Center Operations Manager는 동일한 기능 집합을 공유합니다. 온-프레미스에서 사용하는 것과 동일한 관리 팩을 사용하여 SCOM 관리되는 인스턴스를 통해 네트워크 모니터링을 수행할 수 있습니다.

• SCOM 관리되는 인스턴스는 Azure에 네이티브로 제공되지만 Azure VM에서 System Center Operations Manager를 실행하는 것은 네이티브 솔루션이 아닙니다. 즉, SCOM 관리되는 인스턴스는 Azure와 원활하게 통합되며 모든 Azure 업데이트를 SCOM 관리되는 인스턴스에서 사용할 수 있습니다.
• SCOM 관리되는 인스턴스는 VMSS, Load Balancer, MSI 등을 배포하여 전체 인프라를 고가용성으로 준비합니다. 이러한 설정을 수동으로 준비하려면 수개월의 활동이 필요합니다(심층적인 기술 지식도 필요함).
• SCOM 관리되는 인스턴스는 기본적으로 데이터베이스 관리를 위한 백 엔드로 SQL MI를 사용합니다.
• SCOM 관리되는 인스턴스에는 크기 조정, 패치 기능 및 통합 보고서가 기본 제공되어 있습니다.

동일한 개인 네트워크에 있으므로 네트워크의 각 구성 요소에 할당된 IP가 개인 IP가 될 수 있습니다.

이 인스턴스를 사용하려면 구독에서 SCOM 관리되는 인스턴스를 만들어야 하므로 모든 SCOM 관리되는 인스턴스 리소스(VM 포함)를 볼 수 있습니다. 그러나 예기치 못한 복잡성을 피하기 위해 SCOM 관리되는 인스턴스를 운영하는 동안에는 VM 및 기타 리소스에 대해 어떠한 작업도 수행하지 않는 것이 좋습니다.

아니요.
SCOM 관리되는 인스턴스 관리 게이트웨이는 Operations Manager 게이트웨이 소프트웨어가 없는 모든 Azure 및 Arc 지원 서버에서 구성할 수 있습니다. Operations Manager 온-프레미스 게이트웨이 서버를 SCOM 관리되는 인스턴스와 함께 재사용하려면 해당 서버에서 Operations Manager 게이트웨이 소프트웨어를 제거합니다. SCOM 관리되는 인스턴스 관리 게이트웨이를 구성하려면 SCOM 관리되는 인스턴스 게이트웨이를 통해 서버 모니터링 구성을 참조하세요.

아니요. SCOM 관리되는 인스턴스 관리 게이트웨이에서는 멀티호밍이 불가능합니다.

인증서는 Microsoft에서 할당하고 CA에서 서명합니다. 관리 게이트웨이에서는 인증서를 수동으로 관리할 필요가 없습니다. 

예, VPN/ER을 통해 SCOM 관리되는 인스턴스와 온-프레미스 컴퓨터 간에 직접 연결(가시적인 연결)이 있는 경우 이러한 컴퓨터를 모니터링할 수 있습니다. 자세한 내용은 온-프레미스 서버 모니터링 구성을 참조하세요.

온-프레미스 모니터링 리소스에 대해서는 작업을 수행할 수 없지만 볼 수는 있습니다. 또한 모니터링되는 개체가 삭제되면 포털은 5분 안에 해당 온-프레미스 개체를 자동으로 제거합니다.

모니터링되는 리소스 및 관리되는 게이트웨이 연결 상태는 1분마다 업데이트되며 속성 바로 가기 메뉴에서 동일한 내용을 볼 수 있습니다.

에이전트는 현재 위치에서 업그레이드되고(필요한 경우) SCOM 관리되는 인스턴스에 멀티홈으로 구성됩니다.

이 기능은 SCOM 관리되는 인스턴스 확장이 >=91인 경우 사용하도록 설정됩니다.

속성 바로 가기 메뉴에서 모니터링 리소스 또는 관리 게이트웨이의 속성 목록을 볼 수 있습니다.

SCOM 관리되는 인스턴스를 사용하면 Azure 및 Arc 지원 컴퓨터를 모니터링할 수 있습니다. 또한 SCOM 관리되는 인스턴스에 직접 연결된 온-프레미스 컴퓨터에 대한 정보도 표시합니다.

포털에서 상태 및 연결 상태를 처음 검색하는 데는 약 5~7분이 소요됩니다. 그 후 매분마다 하트비트가 발생합니다.

필요한 최소 .NET Framework 버전은 4.7.2입니다.

온보딩할 에이전트/게이트웨이 서버에서

• *.workloadnexus.azure.com에 대한 아웃바운드 연결이 있는지 확인합니다.
• 이 URL에 대해 방화벽이 열려 있는지 확인합니다.
  예: Test-NetConnection westus.workloadnexus.azure.com -Port 443(지역은 SCOM 관리되는 인스턴스 지역이어야 함)

온보딩할 에이전트/게이트웨이 서버에서 관리 서버 부하 분산 장치 엔드포인트에 대한 아웃바운드 연결이 있는지 확인합니다.
예: Test-NetConnection wlnxMWH160LB.scommi.com -Port 5723

성공적인 온보딩 및 모니터링을 위해서는 에이전트 및 게이트웨이 서버 컴퓨터에서 TLS 1.2 이상이 사용하도록 설정되고 TLS 1.1이 사용하지 않도록 설정되어야 합니다.
자세한 내용은 TLS 1.2 사용하도록 설정 프로세스를 참조하세요.

현재는 Azure 및 Arc 지원 Linux 컴퓨터의 모니터링을 지원하지 않습니다. 그러나 Arc 지원 게이트웨이 서버를 통해 관리할 수 있습니다.

아니요. 여러 SCOM 관리되는 인스턴스와 통신하도록 에이전트를 구성할 수는 없지만 온-프레미스 System Center Operations Manager 및 SCOM 관리되는 인스턴스에 대한 멀티홈 구성을 가질 수 있습니다.

현재는 Arc 지원 컴퓨터만 게이트웨이 서버로 허용됩니다.

현재 게이트웨이 서버에 대한 멀티호밍은 지원되지 않습니다.

다음 단계

다른 FAQ를 읽어보세요.

SCOM 관리되는 인스턴스 개요