本笔记聚焦 Azure SQL Database、Azure SQL Managed Instance、SQL Server on Azure VM 三大服务，涵盖架构定位、迁移选型、高可用与灾难恢复等核心技术点。参考 Microsoft Learn 官方文档整理。

---



## 一、Azure SQL 三大服务定位

### 1.1 SQL Server on Azure VM

**本质**：IaaS 模式下的完整 SQL Server 部署

```
Azure VM
 ↓
Windows / Linux
 ↓
SQL Server 数据库引擎
```

**核心特点**

- 完整的 IaaS 服务模式
- 100% SQL Server 功能兼容性
- 支持 RDP/SSH 远程登录操作系统
- 可安装第三方软件与自定义驱动
- 可自由修改系统级配置
- **全部运维工作由用户自行负责**

**用户运维职责**

```
操作系统管理
SQL Server 配置
补丁更新
备份策略
高可用搭建
故障恢复
监控告警
```

**适用场景**

- 有特殊系统级需求的应用
- 厂商定制化软件
- 需要操作系统访问权限
- 要求 100% SQL Server 兼容

---

### 1.2 Azure SQL Managed Instance

**本质**：PaaS 模式下的 SQL Server 实例级服务

```
SQL Server 实例
│
├─ ERP 数据库
├─ CRM 数据库
└─ OA 数据库
```

**核心特点**

- 完整的 PaaS 服务模式
- 高度兼容本地 SQL Server 实例
- 支持绝大多数实例级功能
- 无法直接访问操作系统
- 微软负责平台底层运维

**支持的实例级功能**

```
SQL Server 代理 (SQL Agent)
链接服务器 (Linked Server)
跨数据库查询
分布式事务 (MS DTC)
数据库邮件 (Database Mail)
```

**适用场景**

- 传统业务系统上云迁移
- ERP、CRM、MES、OA 等企业级应用
- 财务系统等依赖实例级功能的场景

---

### 1.3 Azure SQL Database

**本质**：PaaS 模式下的单数据库服务

```
独立数据库单元
```

**核心特点**

- 最云原生的数据库服务
- 运维负担最小
- 无实例级概念，以单库为单位
- 内置高可用与自动备份

**不强调的功能**

```
SQL Agent（需使用弹性作业替代）
Linked Server
跨数据库事务
```

**适用场景**

- 全新云原生应用开发
- 微服务架构
- 一服务一数据库的设计模式

---

## 二、Server / Instance / Database 层级关系

### 2.1 架构层级

```
物理服务器 (Server)
│
├─ SQL 实例 A (Instance)
│  ├─ ERP 数据库
│  ├─ CRM 数据库
│  └─ OA 数据库
│
├─ SQL 实例 B (Instance)
│  └─ 测试数据库
│
└─ SQL 实例 C (Instance)
   └─ BI 数据库
```

### 2.2 概念对应

|层级|中文名称|说明|
|---|---|---|
|Database|数据库|单个数据存储单元|
|Instance|SQL 实例|一组数据库 + 实例级功能组件|
|Server|服务器|承载实例的操作系统服务器|

---

## 三、Managed Instance 命名含义

**Managed Instance 管理的是 SQL 实例，而非 Windows Server**

|服务类型|交付内容|管理粒度|
|---|---|---|
|Azure SQL Database|给你一个数据库|库级|
|Azure SQL Managed Instance|给你一个 SQL 实例|实例级|
|SQL Server on Azure VM|给你一台完整服务器|服务器级|

---

## 四、传统架构 vs 云原生架构

### 4.1 传统单体架构

**核心特征**：多模块共享数据库，以数据库为中心

```
ERP_DB    CRM_DB    OA_DB
    ↖        ↑        ↗
      应用服务层
```

- 允许跨库查询与跨库事务
- 重度依赖 SQL Agent、Linked Server、MS DTC
- 数据库是系统核心

**典型跨库查询**

```
SELECT * FROM CRM_DB.dbo.Customer
```

**最佳匹配服务**：Managed Instance / SQL VM

---

### 4.2 云原生微服务架构

**核心特征**：一个服务对应一个数据库，服务自治

```
订单服务 → 订单库
库存服务 → 库存库
支付服务 → 支付库
```

- 服务间通过 REST API、消息队列、事件驱动通信
- 数据库归所属服务所有，不允许直接跨库访问
- 理念：**服务调用服务，而非数据库调用数据库**

**正确架构**

```
订单服务
    ↓ API 调用
库存服务
    ↓
  库存数据库
```

**最佳匹配服务**：Azure SQL Database

---

## 五、迁移选型决策指南

### 5.1 选型优先级

传统业务上云优先顺序：

```
Managed Instance (PaaS)
      ↓  不兼容时降级
  SQL VM (IaaS)
```

> 原则：优先使用 PaaS 降低运维负担，遇到兼容性问题再考虑 IaaS

### 5.2 选择 Managed Instance 的条件

- 传统 SQL Server 业务系统迁移
- 需要 SQL Agent 作业调度
- 存在跨数据库查询需求
- 使用 Linked Server 连接外部数据源
- 依赖 MS DTC 分布式事务
- 希望最小化运维工作量

### 5.3 选择 SQL VM 的条件

- 需要 RDP/SSH 远程桌面访问
- 需要操作系统级配置权限
- 必须安装第三方软件或驱动
- 有特殊的安全合规要求
- 要求 100% SQL Server 功能兼容

---

## 六、迁移方式对比

|目标服务|迁移本质|常用方法|兼容性|
|---|---|---|---|
|SQL VM|搬服务器|Backup/Restore、Always On、日志传送、整机迁移|最高|
|Managed Instance|搬数据库实例|Azure DMS、备份到 URL、从 URL 还原|较高（需兼容性评估）|

> 迁移到 Managed Instance 前，建议使用 DMA（数据迁移助手）进行兼容性评估。

---

## 七、连接方式区别

|服务类型|连接地址格式|连接后可见|体验|
|---|---|---|---|
|Azure SQL Database|`server.database.windows.net`|单个数据库|连接即指定库|
|Managed Instance|`my-mi.xxx.database.windows.net`|实例下所有数据库|与本地 SQL Server 一致|
|SQL VM|`ServerName` 或 `ServerName\InstanceName`|完整实例|与本地完全一致|

---

## 八、弹性伸缩能力

|服务类型|伸缩方式|停机影响|管理方|
|---|---|---|---|
|SQL VM|修改虚拟机规格|需要停机重启|用户自行管理|
|Managed Instance|调整 vCore 数量与存储大小|在线调整，业务感知弱|Azure 自动完成|
|Azure SQL Database|调整服务层级与计算大小|在线调整，短暂连接重定向|Azure 自动完成|

---

## 九、高可用（HA）与灾难恢复（DR）

> **常见误区**：HA ≠ DR，二者解决的故障场景不同

### 9.1 高可用（HA）

- **解决问题**：节点故障、服务器故障、系统级故障
- **覆盖范围**：数据中心内
- **提供方式**：Azure SQL Database 和 Managed Instance **默认内置**

### 9.2 灾难恢复（DR）

- **解决问题**：区域级故障（Region Outage）
- **覆盖范围**：跨 Azure 区域
- **提供方式**：需要额外配置，通常产生额外成本

---

## 十、三层容灾防护体系

### 第一层：本地高可用（HA）

- **保护范围**：服务器节点故障、磁盘故障
- **实现方式**：默认内置，基于 Always On 技术
- **用户操作**：无需配置，自动生效

### 第二层：可用区冗余（Zone Redundancy）

- **保护范围**：单个可用区（AZ）故障，如 AZ1 断电、网络中断
- **实现方式**：跨可用区部署副本
- **用户操作**：创建时选择启用，部分服务层级支持

### 第三层：故障转移组（Failover Group）

- **保护范围**：整个 Azure 区域故障，如东亚区全部不可用
- **实现方式**：跨区域数据库复制 + 自动/手动故障转移
- **用户操作**：手动配置，选择配对区域

---

## 十一、PaaS 服务责任边界

### 微软负责

```
平台层高可用
系统补丁更新
自动备份策略
节点故障自动恢复
平台基础设施维护
```

### 客户负责决策

```
是否启用可用区冗余
是否配置故障转移组
是否需要跨区域容灾
备份保留周期策略
```

> 跨区域容灾需要部署额外资源，通常会产生额外费用。

---

## 十二、三大服务架构总览

### SQL Server on Azure VM — 最大控制权

```
Windows / Linux 操作系统
          ↓
    SQL Server 实例
          ↓
ERP_DB  CRM_DB  OA_DB
```

### Azure SQL Managed Instance — 传统迁移最佳目标

```
      SQL Server 实例
      /      |      \
ERP_DB  CRM_DB  OA_DB
```

### Azure SQL Database — 最云原生

```
ERP_DB  CRM_DB  OrderDB  InventoryDB
  ↓       ↓       ↓         ↓
服务A   服务B    服务C      服务D
```

---

## 十三、核心记忆口诀

### 服务选型口诀

```
全新云应用 → Azure SQL Database
传统业务迁移 → Managed Instance
特殊兼容需求 → SQL VM
```

### 容灾层级口诀

```
服务器坏了 → HA（默认自带）
可用区坏了 → Zone Redundancy
整个区域坏了 → Failover Group
```

### 概念区分口诀

```
Database = 一个库
Instance = 一组数据库 + 实例级功能
Server = 操作系统级服务器
```

Azure DP-300数据库基础概念

## 一、故障背景

### 原实验环境已完成配置

- `aa123456.site` 域验证
- Entra Connect 目录同步
- Exchange Online 邮箱创建
- ADFS 联邦身份认证

### 故障触发操作

误删除域控制器（DC）、ADFS、WAP 服务器后，重新部署全套环境，登录出现异常。



## 二、故障现象

访问 `https://outlook.office.com/`，使用 `user01@aa123456.site` 登录时：

1. Outlook 跳转至 Microsoft 365 认证页
2. 重定向到 ADFS 联邦登录页
3. ADFS 账号密码验证成功
4. 跳转回 Microsoft 365 时抛出错误：
    
    > **AADSTS51004**: The user account `R725SnUt5kOLZ6Eye3W0GQ==` does not exist in the directory.
    
![23.png](/static/img/84ed9c5ae9b232dcc99d01b85a08ef4e.23.webp)

## 三、初步排查验证

### 1. 账号存在性

确认 `user01@aa123456.site` 在 Microsoft Entra ID 中正常存在。

### 2. 邮箱状态

Exchange Online 中该账号邮箱完整存在，数据未丢失。

### 3. 目录同步状态

执行 PowerShell 命令查询：

```
Get-MgUser -UserId user01@aa123456.site -Property OnPremisesImmutableId,OnPremisesSyncEnabled
```

返回结果：

- `OnPremisesSyncEnabled : True`
- `OnPremisesImmutableId : hukNzIp+WkihuQKJFPxKYg==`

结论：账号仍标记为本地同步用户。

### 4. 域认证方式

执行命令：

```
Get-MgDomain
```

返回 `AuthenticationType : Federated`，说明登录必须经过 ADFS 联邦认证。

## 四、问题定位

### 1. 计算本地 AD 用户的 ObjectGUID

在本地域控制器执行：

```
$guid = (Get-ADUser user01 -Properties ObjectGUID).ObjectGUID
[System.Convert]::ToBase64String($guid.ToByteArray())
```

输出结果：`R725SnUt5kOLZ6Eye3W0GQ==`

### 2. 对比云端 ImmutableID

- 云端 Entra ID 保存的 ImmutableID：`hukNzIp+WkihuQKJFPxKYg==`
- 本地 AD 用户 ObjectGUID 转 Base64：`R725SnUt5kOLZ6Eye3W0GQ==`

**两者不一致**。

### 3. 检查 ADFS 声明规则

执行命令查看 Office 365 信赖方信任规则：

```
Get-AdfsRelyingPartyTrust -Name "Microsoft Office 365 Identity Platform Worldwide" | Format-List *
```

关键规则逻辑：

> 优先颁发 `mS-DS-ConsistencyGuid` 作为 Immutable ID；若该属性不存在，则颁发 ObjectGUID 作为 Immutable ID。

## 五、根本原因

原环境中 `user01` 同步到 Azure 时，生成的 ImmutableID 为 `hukNzIp+WkihuQKJFPxKYg==`，并保存在云端。 删除 DC 重建后，本地重新创建的 `user01` 生成了全新的 ObjectGUID，ADFS 登录时发出的身份标识变为 `R725SnUt5kOLZ6Eye3W0GQ==`。

云端 Entra ID 仍以旧的 ImmutableID 匹配用户，导致无法识别账号，抛出 `AADSTS51004` 错误。

> 核心：**邮箱和账号本身都正常，问题是 ADFS 签发的 ImmutableID 与云端保存的不匹配**。

## 六、修复步骤

### 1. 将云端 ImmutableID 还原为 GUID 格式

```
$bytes = [System.Convert]::FromBase64String("hukNzIp+WkihuQKJFPxKYg==")
New-Object Guid (,$bytes)
```

输出结果：`ca8d89e1-7e8a-48a9-a1b9-028914fc4a62`

### 2. 给本地 AD 用户写入 mS-DS-ConsistencyGuid

将上述 GUID 写入本地用户的 `mS-DS-ConsistencyGuid` 属性，让 ADFS 优先使用该值签发：

```
$guid = [guid]"ca8d89e1-7e8a-48a9-a1b9-028914fc4a62"
Set-ADUser user01 -Replace @{ 'mS-DS-ConsistencyGuid' = $guid.ToByteArray() }
```

### 3. 触发完整目录同步

```
Start-ADSyncSyncCycle -PolicyType Initial
```

### 4. 结果验证

重新访问 `https://outlook.office.com/`，使用 `user01@aa123456.site` 登录，流程正常，登录成功，邮箱数据完整保留。

## 七、常用排查命令汇总

### 1. 查询同步用户属性

```
Get-MgUser -UserId user01@aa123456.site -Property OnPremisesImmutableId,OnPremisesSyncEnabled,OnPremisesDistinguishedName
```

### 2. 查询域联邦配置

```
Get-MgDomainFederationConfiguration -DomainId aa123456.site
```

### 3. 查询域认证类型

```
Get-MgDomain
```

### 4. 查询本地 AD 用户 GUID 并转 Base64

```
$guid = (Get-ADUser user01 -Properties ObjectGUID).ObjectGUID
[System.Convert]::ToBase64String($guid.ToByteArray())
```

### 5. 查询 ADFS 信赖方声明规则

```
Get-AdfsRelyingPartyTrust -Name "Microsoft Office 365 Identity Platform Worldwide" | Format-List *
```

### 6. Base64 ImmutableID 转 GUID

```
$bytes = [System.Convert]::FromBase64String("hukNzIp+WkihuQKJFPxKYg==")
New-Object Guid (,$bytes)
```

### 7. 设置 AD 用户 mS-DS-ConsistencyGuid

```
$guid = [guid]"ca8d89e1-7e8a-48a9-a1b9-028914fc4a62"
Set-ADUser user01 -Replace @{ 'mS-DS-ConsistencyGuid' = $guid.ToByteArray() }
```

### 8. 手动触发 Entra Connect 同步

```
# 完全同步
Start-ADSyncSyncCycle -PolicyType Initial

# 增量同步
Start-ADSyncSyncCycle -PolicyType Delta
```

## 八、经验总结

### 1. 域重建前置注意事项

删除/重建 DC 前，必须记录所有同步用户的以下关键属性：

- ObjectGUID
- mS-DS-ConsistencyGuid
- UPN（用户主体名称）

### 2. AADSTS51004 错误排查清单

遇到该报错时按顺序检查：

1. 用户账号在 Entra ID 中是否存在
2. 对应 Exchange Online 邮箱是否存在
3. 域名认证类型是否为 Federated（联邦）
4. 用户的 `OnPremisesImmutableId` 值
5. 本地 AD 用户的 `mS-DS-ConsistencyGuid` 属性
6. ADFS 信赖方的声明签发规则

### 3. 核心结论

- 该故障不影响 Exchange Online 邮箱数据
- 问题根源不是 Exchange 服务异常，而是**联邦身份认证的 ImmutableID 不匹配**
- 通过对齐本地 `mS-DS-ConsistencyGuid` 与云端 ImmutableID，即可恢复登录与同步，且不丢失任何邮箱数据

M365联盟域重建后“AADSTS51004”故障处理方法

# **本站第一篇文章**
**第一个内容**


**第二个内容？！**