Azure SQL Hyperscale Revealed High Performance Scalable Solutions For Critical Data Workloads 1St Edition Zoran Barac Full Chapter

Azure SQL Hyperscale Revealed:
High-performance Scalable Solutions

for Critical Data Workloads 1st Edition
Zoran Bara■
Visit to download the full and correct content document:
https://ebookmass.com/product/azure-sql-hyperscale-revealed-high-performance-scal
able-solutions-for-critical-data-workloads-1st-edition-zoran-barac/
Azure SQL Hyperscale
Revealed
High-performance Scalable Solutions
for Critical Data Workloads
Zoran Barać
Daniel Scott-Raynsford
Azure SQL Hyperscale Revealed: High-performance Scalable Solutions for Critical
Data Workloads
Zoran Barać Daniel Scott-Raynsford
Resolution Drive, Auckland, 0930, New Zealand Victory Road, Auckland, 0604, New Zealand
ISBN-13 (pbk): 978-1-4842-9224-2 ISBN-13 (electronic): 978-1-4842-9225-9

https://doi.org/10.1007/978-1-4842-9225-9
Copyright © 2023 by Zoran Barać and Daniel Scott-Raynsford

This work is subject to copyright. All rights are reserved by the Publisher, whether the whole or part of the
material is concerned, specifically the rights of translation, reprinting, reuse of illustrations, recitation,
broadcasting, reproduction on microfilms or in any other physical way, and transmission or information
storage and retrieval, electronic adaptation, computer software, or by similar or dissimilar methodology now
known or hereafter developed.
Trademarked names, logos, and images may appear in this book. Rather than use a trademark symbol with
every occurrence of a trademarked name, logo, or image we use the names, logos, and images only in an
editorial fashion and to the benefit of the trademark owner, with no intention of infringement of the
trademark.
The use in this publication of trade names, trademarks, service marks, and similar terms, even if they are not
identified as such, is not to be taken as an expression of opinion as to whether or not they are subject to
proprietary rights.
While the advice and information in this book are believed to be true and accurate at the date of publication,
neither the authors nor the editors nor the publisher can accept any legal responsibility for any errors or
omissions that may be made. The publisher makes no warranty, express or implied, with respect to the
material contained herein.
Managing Director, Apress Media LLC: Welmoed Spahr
Acquisitions Editor: Jonathan Gennick
Development Editor: Laura Berendson
Editorial Assistant: Shaul Elson
Cover image by Felipe Portella from Unsplash
Distributed to the book trade worldwide by Springer Science+Business Media New York, 1 New York Plaza,
Suite 4600, New York, NY 10004-1562, USA. Phone 1-800-SPRINGER, fax (201) 348-4505, e-mail orders-ny@
springer-sbm.com, or visit www.springeronline.com. Apress Media, LLC is a California LLC and the sole
member (owner) is Springer Science + Business Media Finance Inc (SSBM Finance Inc). SSBM Finance Inc
is a Delaware corporation.
For information on translations, please e-mail booktranslations@springernature.com; for reprint,
paperback, or audio rights, please e-mail bookpermissions@springernature.com.
Apress titles may be purchased in bulk for academic, corporate, or promotional use. eBook versions and
licenses are also available for most titles. For more information, reference our Print and eBook Bulk Sales
web page at www.apress.com/bulk-sales.
Any source code or other supplementary material referenced by the author in this book is available to
readers on GitHub. For more detailed information, please visit www.apress.com/source-code.
Printed on acid-free paper
Table of Contents
About the Authors�� xi
About the Technical Reviewers�� xiii
Introduction��xv
Part I: Architecture�� 1
Chapter 1: The Journey to Hyperscale Architecture in Azure SQL�� 3
SQL on Azure�� 5
The Basics of Azure SQL�� 5
Azure SQL Platform as a Service�� 7
Deployment Models�� 9
Purchasing Models and Service Tiers�� 10
Availability Models and Redundancy�� 13
Standard Availability Model: Locally Redundant Availability�� 15
General Purpose Service Tier: Zone-Redundant Availability�� 16
Premium and Business Critical Service Tier: Locally Redundant Availability�� 18
Premium and Business Critical Service Tier: Zone-Redundant Availability�� 19
Protecting Against Regional Outages Using Failover Groups with
Geo-redundant Availability�� 21
The Hyperscale Service Tier�� 22
Hyperscale Architecture Overview�� 24
Deploying Your First Hyperscale Database�� 25
Cleaning Up�� 34
Summary�� 35
iii
Table of Contents
Chapter 2: Azure SQL Hyperscale Architecture Concepts and Foundations�� 37

Hyperscale Azure SQL Scalability and Durability�� 38
Foundations of Azure SQL Hyperscale�� 40
The Buffer Pool Extension�� 41
The Resilient Buffer Pool Extension�� 41
Investigating the Size of RBPEX�� 41
Row Versioning–Based Isolation Level�� 45
Accelerated Database Recovery�� 48
Multitier Architecture Concepts in Hyperscale�� 49
Compute Nodes�� 50
Log Service�� 58
Page Servers�� 61
Azure Standard Storage�� 68
How Do the Tiers Work Together?�� 70
Summary�� 74
Part II: Planning and Deployment�� 75

Chapter 3: Planning an Azure SQL DB Hyperscale Environment�� 77
Considerations When Planning for Hyperscale�� 77
The Azure SQL Database Logical Server�� 78
Considerations for Reliability�� 81
Considerations for Network Connectivity�� 94
Considerations for Security�� 108
Considerations for Operational Excellence�� 119
Summary�� 124
Chapter 4: Deploying a Highly Available Hyperscale Database

into a Virtual Network�� 125
An Example Hyperscale Production Environment�� 126
The Starting Environment�� 129
The Starting Environment Deployment Script�� 131
iv
Table of Contents
Deploying the Starting Environment Using the Azure Cloud Shell�� 133
Creating a SQL Administrators Group�� 136
Deploying a Highly Available Hyperscale Database into a Virtual Network�� 139
Basic Configuration of the Database�� 141
Configuring Network Connectivity�� 146
The Final Configuration Tasks and Deployment�� 150
Deleting the Example Environment�� 155
Summary�� 157
Chapter 5: Administering a Hyperscale Database in a Virtual Network

in the Azure Portal�� 159
Administering a Hyperscale Database in a Virtual Network�� 160
Deploying a Management VM and Azure Bastion�� 163
Using the Management VM with an Azure Bastion�� 167
Summary�� 170
Chapter 6: Configuring Transparent Data Encryption to Bring Your Own Key�� 171
Enabling Customer-Managed Key Transparent Data Encryption�� 172
Creating a User-Assigned Managed Identity�� 174
Granting the Key Vault Crypto Officer Role to a User�� 175
Generating a Key in the Azure Key Vault�� 178
Granting Access to the Key by the User-Assigned Managed Identity�� 180
Assigning the User-Assigned Managed Identity to the Logical Server�� 182
Enabling Customer-Managed TDE�� 184
Summary�� 185
Chapter 7: Enabling Geo-replication for Disaster Recovery�� 187

Deploying a Hyperscale Geo Replica�� 188
Creating a Logical Server in the Failover Region�� 189
Connecting a Logical Server to a Virtual Network with Private Link�� 191
Enabling the Customer-Managed Key TDE�� 196
Enabling Geo-replication of a Hyperscale Database�� 198
Summary�� 200
v
Table of Contents
Chapter 8: Configuring Security Features and Enabling Diagnostic

and Audit Logs�� 203
Enabling Microsoft Defender for SQL�� 204
Storing Diagnostic and Audit Logs�� 206
Sending Audit Logs to a Log Analytics Workspace�� 207
Sending Database Diagnostic Logs to Log Analytics�� 209
Summary�� 211
Chapter 9: Deploying Azure SQL DB Hyperscale Using PowerShell�� 213

Introduction to Infrastructure as Code�� 214
Imperative vs. Declarative Infrastructure as Code�� 215
Deploying Hyperscale Using Azure PowerShell�� 216
The Azure PowerShell Modules�� 216
Deploying the Starting Environment�� 218
The Complete Deployment PowerShell Script�� 218
Azure PowerShell Commands in Detail�� 220
Summary�� 239
Chapter 10: Deploying Azure SQL DB Hyperscale Using Bash and Azure CLI�� 241
Deploying Hyperscale Using the Azure CLI�� 241
The Azure CLI�� 242
Deploying the Starting Environment�� 243
The Complete Deployment Bash Script�� 245
Azure CLI Commands in Detail�� 247
Summary�� 264
Chapter 11: Deploying Azure SQL DB Hyperscale Using Azure Bicep�� 267
About Azure Bicep�� 268
Deploying Using Azure Bicep�� 268
A Complete Azure Bicep Deployment�� 268
Hyperscale Resources in Azure Bicep�� 271
Summary�� 284
vi
Table of Contents
Chapter 12: Testing Hyperscale Database Performance Against Other

Azure SQL Deployment Options�� 285
HammerDB�� 286
HammerDB TPROC-C Workload�� 287
HammerDB Step-by-Step�� 287
Schema Build Performance Metrics�� 301
TPROC-C Workload Metrics�� 312
Summary�� 336
Part III: Operation and Management�� 339

Chapter 13: Monitoring and Scaling�� 341
Monitoring Platform Metrics�� 342
Viewing Metrics with the Metrics Explorer�� 342
Streaming Metrics to a Log Analytics Workspace�� 344
Alerting on Platform Metrics�� 345
Monitoring and Tuning Database Performance�� 351
Monitoring Query Performance�� 351
Performance Recommendations�� 352
Automatically Tuning Database Performance�� 352
Gathering Insights from the Database�� 353
SQL Analytics�� 354
Scaling a Hyperscale Database�� 357
Manually Scaling Up a Hyperscale Database�� 358
Manually Scaling Out a Hyperscale Database�� 359
Autoscaling a Hyperscale Database�� 360
Summary�� 360
Chapter 14: Backup, Restore, and Disaster Recovery�� 361

Hyperscale Database Backups�� 361
Backup Retention Policy�� 362
Backup Storage Redundancy�� 365
Monitoring Backup Storage Consumption with Azure Monitor Metrics�� 367
vii
Table of Contents
Hyperscale Database Restores�� 368

Example 1: Restore to Same Region, LRS to LRS�� 369
Example 2: Restore to Same Region, LRS to GRS�� 371
Example 3: Restore to the Same Region, GRS to GRS�� 372
Example 4: Geo Restore to Different Region, GRS to LRS�� 372
Example 5: Geo-restore to Different Region, GRS to GRS�� 373
Comparing Restore Performance of Hyperscale to Traditional Azure SQL Databases�� 375
Disaster Recovery�� 377
Summary�� 379
Chapter 15: Security and Updating�� 381

Azure SQL Database Security Overview�� 381
Network Security�� 384
Access Management�� 387
Auditing and Azure Threat Detection�� 390
Information Protection�� 392
Updating and Maintenance Events�� 396
Summary�� 398
Chapter 16: Managing Costs�� 399

Azure Hybrid Benefit�� 399
Reserving Capacity�� 401
Purchasing Reserved Capacity�� 401
Estimating Reserved Capacity Benefits�� 402
Utilizing Reservations�� 402
Scaling In and Scaling Down Replicas�� 403
Summary�� 405
Part IV: Migration�� 407

Chapter 17: Determining Whether Hyperscale Is Appropriate�� 409
Key Considerations for Hyperscale�� 409
Scalability�� 410
Reliability�� 413
viii
Table of Contents
Business Continuity�� 413

Cost�� 416
Summary�� 418
Chapter 18: Migrating to Hyperscale�� 419

Common Migration Methods�� 419
In-Place Conversion of an Azure SQL Database to Hyperscale�� 421
Migrating to Hyperscale with Data Migration Assistant�� 425
Migrating to Hyperscale with the Azure Database Migration Service�� 432
Migrating with ADS with the Azure SQL Migration Extension�� 443
Migrating to Hyperscale Using Import Database�� 444
Migrating to Hyperscale Using a Data Sync and Cutover�� 446
Summary�� 447
Chapter 19: Reverse Migrating Away from Hyperscale�� 449

Reverse Migration Methods�� 450
Reverse Migration Using the Azure Portal�� 450
Reverse Migration Using Transact SQL�� 453
Reverse Migration Using Azure CLI�� 454
Common Pitfalls of the Reverse Migration Process�� 456
Migrating to an Unsupported Service Tier�� 456
Database Not Eligible for Reverse Migration�� 457
Summary�� 457
Chapter 20: Conclusion�� 459
Index�� 461
ix
About the Authors
Zoran Barać is a cloud architect and data specialist
with more than 15 years of hands-on experience in
data optimization, administration, and architecture. He
is a Certified Microsoft Trainer (MCT) and Microsoft
Certified Solutions Expert (MCSE) with a master‘s degree
in information technology. Sharing knowledge and
contributing to the SQL Server community are his passions.
He is also an organizer of the Auckland SQL User Meetup
Group, an active blogger, and a speaker at different SQL events such as Data Summits,
SQL Saturdays, SQL Fridays, meetups, etc.
Daniel Scott-Raynsford is a partner technology strategist

at Microsoft with 15 years of experience as a software
developer and solution architect. He specializes in DevOps
and continuous delivery practices. He was a Microsoft MVP
in cloud and data center management for three years before
joining Microsoft and is an active PowerShell open-source
contributor and Microsoft DSC Community Committee
member. He is also a contributor to the Azure Architecture
Center on multitenant architecture practices.
xi
About the Technical Reviewers
Jonathan Cowley is a cloud infrastructure engineer,
DevOps practitioner, and technical documentation writer
with more than 15 years of experience in various roles and
environments, in both small and large corporations and
public organizations. He has been Microsoft Azure and AWS
certified. He enjoys connecting people and information and
solving challenging problems.
Vitor Fava has earned the title of Most Valuable Professional

(MVP AI and Data Platform) and the main certifications
related to SQL Server, such as MCP, MCTS, MCITP, MCSA,
and MCSE. A DBA with more than 20 years of experience
in database and information technology, Vitor works on
the development, implementation, maintenance, and
support of large corporate database servers. Vitor graduated
with a degree in information systems from Universidade
Presbiteriana Mackenzie/SP, with an emphasis on high-
performance and mission-critical database environment
management.He has been a speaker at several technology events, such as SQLBITS,
SQL Saturday, The Developers Conference (TDC), SQL Porto, InteropMix, and several
discussion groups focused on database technology. Vitor also provides advanced
training in SQL Server and Azure SQL Database, in addition to acting as an MCT
in official Microsoft training. He is also the chapter leader of the PASS Chapter SQL
Maniacs in São Paulo, Brazil.
xiii
Introduction
Azure SQL is a platform-as-a-service (PaaS) relational database management system
(RDBMS) that is provided as part of the Azure cloud and based on the Microsoft SQL
Server platform. This offering contains service tiers that make it suitable for a wide
range of use cases, from small single-user applications to mission-critical lines of
business workloads. However, there is only one service tier that provides the high level
of scalability and resilience that is required by some of today’s largest cloud-based
workloads: Hyperscale.
In this book, we’ll take you through the capabilities and basics of the Azure SQL
Database Hyperscale service tier. You’ll learn the basics of designing, deploying, and
managing Azure SQL Hyperscale databases. We’ll look in detail at the resilience (high
availability and disaster recovery) and scalability of Azure SQL Hyperscale databases and
how to tune them. We will also look at the different techniques you can use to deploy and
configure Azure SQL Hyperscale.
Monitoring and securing Azure SQL Hyperscale databases will also be covered to
ensure your workloads continue to perform and operate securely. This book will be your
guide to deciding when Hyperscale is a good fit for migrating your existing workloads
and what architectural considerations you should make in your application. Finally,
you’ll learn how to migrate existing workloads to Azure SQL Database Hyperscale.
This book is intended for data architects, software engineers, cloud engineers,
and site reliability engineers and operators to learn everything they need to know to
successfully design, deploy, manage, and operate Azure SQL Database Hyperscale.
You’ll learn what makes Azure SQL Database Hyperscale architecture different
from a more traditional database architecture and why it’s important to understand the
architecture.
To get the most out of this book, you should have a basic knowledge of public cloud
principles and economics as well as a fundamental knowledge of Azure, Microsoft SQL
Server, and RDBMSs. It is not required to have experience using Azure SQL Database.
This book will provide you with everything you need to know to effectively build and
operate the Hyperscale tier of Azure SQL Database without prior experience.
xv
Introduction
Although this book covers concepts that apply to Azure SQL Database in general,
it is intended to provide everything you need to know to run an Azure SQL Database
Hyperscale tier in Azure without requiring any other material. You may find content that
is covered in other more general books on running SQL in Azure, but this book looks at
these concepts through the Hyperscale lens. Hyperscale has special use cases that make
it unique, which also require specific knowledge to get the most out of it.
Thank you for venturing into the world of Hyperscale database technology.
A note about the recently announced automatic compute scaling with serverless for
Hyperscale in Azure SQL Database: At the time of writing this book, the possibility of
an automatically scaling Hyperscale with a serverless compute tier was merely an item
on the roadmap. We did not, therefore, cover it in detail, even though we were aware it
was planned. However, serverless Hyperscale has just arrived in public preview. This
development does not change the guidance provided in this book, but serverless should
be considered for Hyperscale workloads that need high levels of elasticity. It is yet another
tool in the amazing array of data storage services available in Microsoft Azure and should
be on your list of considerations when determining if Hyperscale is right for you.
Serverless Hyperscale automatically adjusts the compute resources of a database
based on its workload and usage patterns. It also allows different replicas of the
database to scale independently for optimal performance and cost efficiency. Serverless
Hyperscale is different from provisioned compute Hyperscale, which requires a fixed
number of resources and manual rescaling.
For more information on the serverless Hyperscale announcement, see this page
https://techcommunity.microsoft.com/t5/azure-sql-blog/automatic-compute-
scaling-with-serverless-for-hyperscale-in/ba-p/3624440.
xvi
CHAPTER 1
The Journey to
Hyperscale Architecture
in Azure SQL
Every day, many billions or even trillions of transactions are processed by the ever-
growing number of Azure SQL databases deployed globally in the Microsoft Azure public
and government clouds. The number of transactions and the size of these databases
are continuously increasing. The accelerating adoption of public cloud technology has
enabled new use cases for Azure SQL databases as well as the migration of larger line-of-
business applications from on-premises SQL servers.
As the public cloud continues to mature, businesses are moving more of their
mission-critical workloads to Azure. This results in the need to support larger and larger
databases.
Accompanying this move to the cloud, the demand for IT departments and
engineering teams to provide more application features with greater resilience and
security has also increased. This pressure has caused organizations to look at how
they can cut down on the operational costs of maintaining their infrastructure. The
requirement to reduce operational expenditure has led toward running more databases
as platform-as-a-service (PaaS) solutions—where the cloud provider takes care of the
day-to-day operations of the infrastructure—freeing the organization to focus on higher-
value tasks.
As well as the migration of enterprise-scale databases, an increase in the adoption
of software-as-a-service (SaaS) solutions by consumers and organizations has led to
SaaS providers needing larger databases, higher transaction throughput, and increasing
resilience—while also being able to scale quickly.
3
© Zoran Barać and Daniel Scott-Raynsford 2023
Z. Barać and D. Scott-Raynsford, Azure SQL Hyperscale Revealed,
https://doi.org/10.1007/978-1-4842-9225-9_1
Chapter 1 The Journey to Hyperscale Architecture in Azure SQL
This explosive shift by organizations to adopting SaaS has also facilitated a need by
SaaS providers to manage costs as they scale. This has often resulted in a change from a
single database per tenant to a multitenant approach. A multitenant approach can help
to reduce costs, but it also increases the need for larger capacities and throughput, while
being able to assure isolation and avoid challenges such as noisy neighbors. For an in-
depth explanation on that, see https://learn.microsoft.com/azure/architecture/
antipatterns/noisy-neighbor/noisy-neighbor.
The growth trend toward SaaS is expected to continue as organizations and SaaS
providers accommodate the expectations of their customers to gain greater value
from their data with analytics and machine learning. This growth in demand for better
analytics and machine learning abilities also facilitates the need to collect more data,
such as usage telemetry and customer behavior data.
New types of application workloads and patterns, such as event streaming
architectures and the Internet of Things (IoT), have also increased the demands on
relational database management systems. Although alternative architectures exist to
reduce the impact of these application workloads on the relational database, they don’t
completely mitigate the need for larger relational databases as a part of applications.
Customers are expecting solutions that can integrate with and accept data from other
services and data sources. This is leading organizations and SaaS providers to build a
greater level of integration into their software and also to be seen as platforms with an
ecosystem of third-party applications and extensions springing up around them. This is
further pushing the scale and elasticity required by the relational database management
system (RDBMS) underlying these platforms.
Applications are also consuming data from more and more systems and providing
their own combined insights and enhancements. For example, applications that
integrate with Microsoft Teams might retrieve calling and messaging data and combine
it with other data sources to provide additional functionality. As the volume of data
increases within these systems, so does the need for more capacity in the application
database that collects it.
Azure provides the Azure SQL Database service, a PaaS product, that includes
several different tiers offering options for capacity and resilience while also enabling a
high degree of scale.
The changing data landscape, driven by the cloud, SaaS, and newer workloads, has
resulted in the need for a design change to the Azure SQL Database architecture to be
pushed to the limit, requiring a completely new internal architectural approach: the
Hyperscale architecture.
4
Hyperscale is the newest service tier of the Azure SQL Database and provides
highly scalable compute and storage that enables it to significantly exceed the limits of
the other tiers of service. This is achieved by substantial alterations to the underlying
architecture. These changes are discussed in more detail in Chapter 2.
Tip Throughout this book we’ll often refer to the Azure SQL Database Hyperscale
service tier as just Hyperscale to make it easier on you, the reader.
At its core, Hyperscale helps us address these changing requirements, without

the need to adopt radically different architectures or fundamentally change our
applications—which in this new world of high demand for applications and features is a
great thing.
SQL on Azure
It’s been a long and progressive journey of more than 12 years from the beginnings of
Azure SQL called CloudDB all the way up to the new Azure SQL Database Hyperscale
service tier and Hyperscale architecture.
Before we can get into the details of Hyperscale, we will start by looking at the
different ways that SQL workloads can be hosted in Azure. This will give us a view of
where Hyperscale fits within the portfolio and when it is a good choice for a workload.
The Basics of Azure SQL

There are many benefits to hosting your data workloads in the cloud. Whether you
want to utilize modern cloud offerings using Azure SQL Database, migrate an existing
workload and retain your current SQL Server version running on an Azure virtual
machine (VM), or simply adopt the newest SQL Server features, Azure SQL might be the
right choice for you.
Fundamentally, there are two distinct ways SQL workloads can be deployed in Azure.
• As infrastructure as a service (IaaS) using SQL Server on Azure VMs

• As a platform as a service (PaaS) using Azure SQL Database (DB) or
Azure SQL Managed Instance (MI)
5
Both Azure SQL deployment types (IaaS and PaaS) offer you redundant, secure, and
consistent cloud database services. However, with IaaS you are responsible for more of
the system, requiring a greater amount of effort from you in maintaining and ensuring
the system is resilient and secure.
Tip Azure SQL MI is a PaaS database service with a higher level of isolation and
compatibility with SQL Server on Azure VMs or on-premises SQL Servers.
Running SQL Server on Azure VMs provides you with the ability to configure every
aspect of the underlying infrastructure, such as compute, memory, and storage as well
as the operating system and SQL Server configuration. This high level of configurability
comes with an increased operational cost and complexity. For example, operating
system and SQL Server upgrades and patching are the user’s responsibility.
By comparison, Azure SQL DB (and Azure SQL MI) is a managed database service
where users do not need to worry about SQL Server maintenance tasks—such as
upgrades, patching, or backups—or service availability. The Azure platform abstracts
and manages these important aspects of your environment automatically, significantly
reducing operational costs and complexity. This often results in a much lower total cost
of ownership (TCO).
Generally, PaaS provides significant benefits that make it extremely attractive;
however, in some cases, IaaS is still required. Some applications might need access to the
underlying SQL instance or features of SQL Server that are not available on Azure SQL DB.
Tip For some workloads that need features that Azure SQL DB does not provide,
Azure SQL MI might still be an option. This could still allow the workload to be
moved to Azure, while leveraging the significant benefits of PaaS. For a comparison
between Azure SQL DB and Azure SQL MI features, see https://learn.
microsoft.com/azure/azure-sql/database/features-comparison.
Workloads that are being migrated from on-premises or a private cloud often require
IaaS when they are first migrated into Azure but will be able to be re-platformed onto
Azure SQL DB after some modernization. The benefits of this usually far outweigh the
engineering costs of modernization. Another reason that IaaS might be needed is to gain
a higher level of infrastructure isolation for regulatory compliance reasons.
6
Figure 1-1 compares the administration needs and costs of on-premises, private
cloud machines, IaaS, and PaaS. We can see that PaaS has lower administration needs
and costs than IaaS.
Figure 1-1. Continuum of cost and administration of different hosting models
We will be focusing primarily on Azure SQL DB, as this is the only deployment model
that supports the newest service tier: Hyperscale.
Azure SQL Platform as a Service

When you select Azure SQL PaaS, you are getting a fully managed database service.
Whichever deployment model you choose, you will always have some level of
redundancy, starting with local redundancy and if available zone or geo-redundancy.
7
There are four key decisions you need to make when deploying a SQL workload
on Azure.
1. Choose a deployment model.
2. Specify a purchasing model.
3. Specify a service tier.
4. Choose an availability model; this will depend on which service
tiers you deployed.
Figure 1-2 shows a map of the deployment models, purchasing models, service tiers,
and availability models available when selecting Azure SQL PaaS. As this book is all
about Hyperscale, the most important area is the Hyperscale service tier.
Figure 1-2. Azure SQL DB deployment models, purchasing models, service tiers,
and availability models
8
Deployment Models
The PaaS deployment models are divided into two types.
• Azure SQL Database
• Azure SQL Managed Instance
When you deploy an instance of Azure SQL DB, you have two deployment options:
a single database or elastic pools. When using elastic pools, you can allow multiple
databases to share a specified number of resources at a set price.
Tip Elastic pools are an excellent model for building SaaS applications, where
each tenant has their own database; however, elastic pools don’t currently support
Hyperscale.
Azure SQL MI offers both single-instance and instance pool deployment options.
Single instance supports only a single SQL Server instance, while instance pools allow
multiple SQL Server instances.
Table 1-1 shows the deployment options available with Azure SQL PaaS, as well as
the features and recommended use cases.
9
Table 1-1. Azure SQL PaaS Deployment Options

Managed Instances Databases
Single Instance Instance Pool Single Database Elastic Pool
• Fully managed service.
• Minimum four • Hosting instance • Hyperscale Service • Price optimization—
vCores per instance. with smaller core tier availability. shared resources.
• 16TB size storage number (two • Serverless compute • Ability to limit
for the General vCores). tier for the General necessary resources
Purpose service tier. Purpose service tier. per database.
• Supports most on-premises instance/ • The most used SQL Server features are
database-level capabilities. supported.
• High compatibility with SQL Server • 99.99 percent to 99.995 percent availability
on-premises. guaranteed.
• At least 99.99 percent availability • Built-in backups, patching, recovery.
guaranteed. • Latest stable database engine version.
• Built-in backups, patching, recovery.
• Latest stable database engine version.
• Easy migration from SQL Server.
Tip You can use the Azure Portal to check the usage and properties for an
existing MI pool, but not to deploy a pool. Instead, use a PowerShell session or the
Azure CLI.
Purchasing Models and Service Tiers

Within Azure SQL all deployment offerings are provisioned on virtual infrastructure.
Purchasing models and service tiers define the back-end hardware capabilities for specific
deployments, such as machine instance and CPU generation, vCores, memory, and
capacity. You need to consider the ideal hardware configuration based on your workload
requirements. The exact offerings can vary depending on your deployment region.
10
Figure 1-3 shows the compute tier and hardware configuration for the General
Purpose service tier for the Azure SQL Database deployment option.
Figure 1-3. Service and compute tier: Azure SQL DB General Purpose service tier
There are two different purchasing models—vCore and DTU—each with multiple
service tiers. The DTU purchasing model is based on data transaction units (DTUs).
DTUs are a blended measurement of a machine’s specifications—CPU, memory, reads,
and writes. Figure 1-4 shows available purchasing models and service tiers for single
Azure SQL Database deployment.
11
Figure 1-4. Single Azure SQL DB purchasing models and service tiers available
Tip For more information on DTU modeling, review this page: https://learn.
microsoft.com/azure/azure-sql/database/service-tiers-dtu.
There are multiple service tier options within the DTU purchasing model:
• Basic: Use for less demanding workloads: up to 5 DTU, up to 2GB

data, read latency of 5ms, and write latency of 10ms.
• Standard: Use for workloads with typical requirements: up to 3000

DTUs (S12), up to 1TB data, read latency of 5ms, and write latency
of 10ms.
• Premium: Use for I/O-intensive workloads: up to 4000 DTUs, up to

4TB data, read and write latency of 2ms, read scale-out and zone-
redundant options available.
The vCore purchasing model represents a choice of specific virtual hardware

specifications. You select the generation of the hardware—starting with the CPU
configuration, number of cores, maximum memory, and storage capacity. This model is
transparent and cost efficient and gives you the flexibility to translate your on-premises
workload infrastructure requirements to the cloud.
12
There are multiple service tier options within the vCore purchasing model.
• General Purpose
• Azure SQL DB: 2–128 vCores, up to 625GB memory, and up to

4TB data.
• Azure SQL MI: 4–80 vCores, Standard-series 5.1GB RAM/vCore,

and up to 16TB data. Premium-series 7GB RAM/vCore, and up to
16TB data.
• Azure SQL DB Serverless: 0.5–80 vCores, up to 240GB memory,

and up to 4TB data.
• Business Critical
• Azure SQL DB: 2–128 vCores, up to 625GB memory, and up to

4TB data.
• Azure SQL MI: 4–80 vCores, Standard-series 5.1GB RAM/vCore

and up to 4TB data. Premium-series 7GB RAM/vCore, and up to
16TB data.
• Hyperscale
• Standard-series (Gen5): 2–80 vCores, up to 415GB memory, and

up to 100TB data.
• Premium-series: 2–128 vCores, up to 625GB memory, and up to

100TB data.
• Premium-series memory-optimized: 2–128 vCores, up to 830GB

memory, and up to 100TB data.
• DC-series (enables confidential computing): 2–8 vCores, up to

36GB memory, and up to 100TB data.
You can choose the vCore purchasing model only for managed instances with the
General Purpose or Business Critical service tier.
Availability Models and Redundancy

There are two main availability models in Azure SQL PaaS offerings.
13
• Standard: Separates compute and storage tiers. It relies on the

high availability of the remote storage tier. This can result in some
performance degradation during maintenance activities, so it is
suitable for more budget-conscious users.
• Premium: Like the Always On availability option for VMs. It relies on

a failover cluster of database engine processes. It is more reliable as
there is always a quorum of available database engine nodes. This
suits mission-critical applications with high I/O performance needs.
It minimizes any performance impact to your workload during
maintenance activities.
Depending on which service tiers you deployed, it may leverage the Standard
availability architecture for the Basic, Standard, and General Purpose service tiers or the
Premium availability architecture for the Premium and Business Critical service tiers.
There are three types of redundancy when running SQL workloads in Azure.
• Local redundancy: All Azure SQL PaaS deployments offer local

redundancy. Local redundancy relies on the single data center being
available.
• Zone redundancy: This replicates a database across multiple

availability zones within the same Azure region. Azure availability
zones are physically separate locations within each Azure region that
are tolerant to local failures. To enable zone redundancy, you need to
deploy your services within a region that supports availability zones.
This protects your workload against failure of a single availability
zone. For more information on Azure availability zones, see this page:
https://learn.microsoft.com/azure/availability-zones/az-
overview.
• Geo-redundancy: There are multiple ways to achieve geo-redundancy

using failover groups (FOGs) or active geo-replication. Geo-
replication is an Azure SQL Database business continuity and
disaster recovery feature (asynchronous replication). This protects
your workload against failure of an entire region.
14
Tip Zone-redundant configuration is available only for Azure SQL Database

deployment and only for Gen5 hardware or newer. Using zone-redundant
configuration with SQL Managed Instance is not currently supported.
Depending on which service tier you select, it may leverage either the Standard or
Premium availability architecture model.
• Standard availability model: DTU purchasing model Basic and

Standard service tiers and vCore purchasing model General Purpose
service tier
• Premium availability model: DTU purchasing model Premium

service tier and vCore purchasing model Business Critical
service tiers
tandard Availability Model: Locally

S
Redundant Availability
Basic, Standard, and General Purpose service tiers leverage the Standard availability
model, which offers resilience to failure using locally redundant remote Azure Premium
storage to store data and log files (.mdf and .ldf files). Backup files are stored on geo-
redundant Azure Standard storage. High availability is accomplished in a similar way
for the SQL Server Failover Cluster Instance (FCI), by using shared disk storage to store
database files.
Figure 1-5 shows the Azure SQL PaaS Standard availability model architecture used
by the Basic, Standard, and General Purpose service tiers.
15
Figure 1-5. Azure SQL PaaS Standard availability model architecture
General Purpose Service Tier: Zone-Redundant Availability

Like Basic and Standard, the General Purpose service tiers leverage the Standard availability
model. In addition to local redundancy, which is included with all Azure SQL PaaS
deployment options, the General Purpose service tiers can offer zone redundancy as well.
This provides resilience to failure across different availability zones within the same
region. Zone-redundant configuration for serverless and provisioned General Purpose
tiers are available in only some regions.
16
Tip Be aware that with the General Purpose service tier, the zone-redundant
option is available only when the Gen5 (or newer) hardware configuration is
selected. Selecting zone redundancy incurs an additional cost.
Figure 1-6 shows the Azure SQL PaaS Standard availability model with zone
redundancy used by the General Purpose service tier.
Figure 1-6. Azure SQL PaaS Standard availability model with zone
redundancy enabled
17
remium and Business Critical Service Tier: Locally

P
Redundant Availability
The Premium and Business Critical service tiers leverage the Premium availability
model, which offers resilience to failure using multiple replicas in synchronous data
commit mode. Every replica has integrated compute and storage, which means that
every node has an attached solid-state disk (SSD) with databases and log files on it (.mdf
and .ldf files). High availability is accomplished in a similar way as with SQL Server
Always On availability groups, by replicating nodes across the cluster using synchronous
data commit mode.
Figure 1-7 shows the Azure SQL PaaS Premium availability model architecture used
by the Premium and Business Critical service tiers.
18
Figure 1-7. Azure SQL PaaS Premium availability model architecture
remium and Business Critical Service Tier:

P
Zone-Redundant Availability
As mentioned earlier, the Premium and Business Critical service tiers leverage the
Premium availability model, which offers resilience to failure using multiple replicas
in synchronous data commit mode. Moreover, the zone-redundant deployment option
provides additional resilience to an Azure availability zone (AZ) failure, if the failure is
19
confined to a single AZ rather than an entire region. High availability is accomplished

in a similar way for SQL Server Always On availability groups, replicating nodes across
multiple availability zones in synchronous data commit mode.
Tip Azure SQL Database service tiers using the Standard availability model
provides a greater than 99.99 percent uptime availability guarantee. Nevertheless,
Premium and Business Critical service tiers—leveraging the Premium availability
model with zone-redundant deployments—provide a greater than 99.995 percent
uptime guarantee.
Figure 1-8 shows the Azure SQL PaaS Premium availability model with zone
redundancy enabled for the Premium and Business Critical service tiers.
20
Figure 1-8. Azure SQL PaaS Premium availability model with zone
redundancy enabled
rotecting Against Regional Outages Using Failover

P
Groups with Geo-redundant Availability
To protect your SQL instance against failure of an entire Azure region and to achieve
geo-redundancy with good disaster recovery capability, you can use failover groups.
Failover groups enable asynchronous replication between multiple Azure regions (or
within regions).
21
Figure 1-9 shows geo-replication using failover groups via asynchronous replication
between multiple Azure regions.
Figure 1-9. Geo-replication between multiple Azure regions using failover groups
The Hyperscale Service Tier

A traditional monolithic cloud architecture has its purposes but has several limitations,
in particular relating to large database support and length of recovery time. For the
past decade, Microsoft has been aiming to develop a new architecture model that can
override these issues.
22
The goal of the new model has been to decouple compute, storage, and log services,
while at the same time offering highly scalable storage and compute performance tiers.
At the time of writing, there is an Azure SQL database deployment model and the
Hyperscale service tier under the vCore purchasing model, which leverages a new
architecture, which in this book we will call the Hyperscale architecture.
Table 1-2 compares the traditional Azure SQL architecture and the Azure Hyperscale
architecture.
Tip Hyperscale is available only under the Azure SQL Single Database

deployment option; you cannot use the Hyperscale service tier with elastic pool
deployment.
Table 1-2. Traditional Azure SQL Architecture vs. Azure Hyperscale Architecture
Traditional Architecture Hyperscale Architecture
Max Azure SQL DB: 4TB. 100TB.

Storage Azure SQL MI Business
Size Critical: 5.5TB.
Azure SQL MI General
Purpose: 16TB.
CPU Up to 128 vCores. Standard-series (Gen5): Up to 80 vCores.
Premium-series: Up to 128 vCores.
Memory Standard-series (Gen5): Standard-series (Gen5): up to 415.23 GB memory.
up to 625 GB memory. Premium-series: up to 625 GB memory.
Premium-series (memory optimized): up to 830.47 GB
memory.
Latency Premium availability Latency can vary and mostly depends on the workload and
model: 1–2ms. usage patterns.
Standard availability Hyperscale is a multitiered architecture with caching at
model: 5-10ms. multiple levels, data being accessed primarily via a cache
on the compute node. In such cases, average latency will
be similar as for Business Critical or Premium service tiers
(1–2ms).
(continued)
23
Table 1-2. (continued)
Traditional Architecture Hyperscale Architecture
Log Depending on vCores 105MB/s regardless of the number of vCores.

Throughput number.
Up to 96 MB/s per node.
Log Size Up to 1TB log size. Unlimited log size.
Read 1 read scale-out replica. Up to 4 HA/Read scale-out replicas.
scale-out Up to 30 named replicas.
Backup Depending on database Snapshot-based backup and restore operations do not
and size. depend on database size.
Restore
Tip The main question you should ask yourself is whether your data workload
demands are exceeding the limits of your current Azure SQL service tier—in which
case you might consider moving your data workload to a more suitable service tier
such as Azure SQL Hyperscale, leveraging the Hyperscale architecture scale-out
capability.
Hyperscale Architecture Overview

Azure SQL Hyperscale utilizes the four-tier architecture concept, which includes the
remote durable storage service to achieve superior performance, scalability, and
durability. Figure 1-10 shows the four-tier Hyperscale architecture concept of decoupling
the compute layer from log services and scale-out storage.
24
Figure 1-10. Four-tier Hyperscale architecture concept
Deploying Your First Hyperscale Database

Now that we have covered the basic options available when deploying a SQL workload
in Azure, it’s time to provision our very first Hyperscale database. For this, we’re going to
use a user interface–driven process in the Azure Portal.
25
Tip Deploying services using the Azure Portal is a great way to get started,
but it is strongly recommended that as you mature in your use of Azure, you
adopt infrastructure as code. To learn more about infrastructure as code,
refer to https://learn.microsoft.com/devops/deliver/what-is-
infrastructure-as-code. We will favor using infrastructure as code in the
examples throughout this book.
You will need access to an Azure subscription that you have appropriate permissions
to create new services in. The Contributor or Owner role in the Azure subscription will
be adequate permissions. If you’re not the subscription owner, you should first check
with the account owner for the subscription if you may deploy a Hyperscale database as
there will be a cost for every hour that you have the service deployed.
Tip If you don’t have access to an Azure subscription, you can sign up for a free
Azure one with USD $200 credit to use within 30 days; see https://aka.ms/
AzureFree. After you have consumed the USD $200 credit, the free services will
still be available to you for one year, but unfortunately the Hyperscale tier of Azure
SQL DB is not currently among the free services.
The Azure Portal is under constant improvements, and it is quite possible that the
user interface you see by the time this book is released will be slightly different. But
the fundamental elements should remain. That is a reason why we will provide many
examples as code.
In our example, we’re going to deploy a zone-redundant Hyperscale database with
two vCores running on Gen5 hardware in the Azure East US region with one high-
availability secondary replica.
So, let’s get started.
1. Open your browser and navigate to https://portal.azure.com.
2. Sign in using credentials that give you access to the Azure
subscription you’ll be deploying your Hyperscale database into.
3. Click the “Create a resource” button in the home dashboard.
26
4. Click Create under SQL Database on the “Create a

resource” blade.
5. The Create a SQL Database blade will open showing the Basics
configuration options of our database.
27
6. Make sure Subscription is set to the name of the subscription you

have permission to deploy into.
7. Set the resource group to an existing resource group that you want
to create your Hyperscale database into or click New to create
a new resource group. In our example, we are going to create
our hyperscale resources in an existing resource group called
sqlhyperscalerevealed-rg that is in the Azure East US region.
8. Enter the name of the Hyperscale database to create in the

“Database name” box. We are using hyperscaledb for this
example.
9. Although Azure SQL Database is a PaaS service, there is still
an underlying SQL Database server. We need to create a new
logical instance of a SQL Database server by clicking the “Create
new” button.
28
10. Every SQL Database server must have a unique name, not just
within our environment, but globally. For this example, we are
using sqlhyperscalerevealed01, but you should use a name that
is likely to be globally unique.
11. Set the location to the Azure region in which you want to deploy
the SQL Database server. This is the Azure region where your
Hyperscale database will be stored and should usually be as
geographically close to your application or users as possible.
Important Azure SQL Database Hyperscale is enabled in most Azure

regions. However, if it is not enabled in the region you chose, select an
alternate region, or see this page for more information: https://learn.
microsoft.com/azure/azure-sql/database/service-tier-
hyperscale?view=azuresql#regions.
12. Set the authentication method to “Use only Azure Active Directory
(Azure AD) authentication.”
Tip You can choose to use SQL authentication or to use both SQL and Azure AD
authentication, but it is recommended you use Azure AD authentication to enable
the central management of identities. However, some third-party applications may
not support this. We will cover security best practices in detail in Chapter 15.
13. Click the “Set admin” button to select the Azure AD user or
group that will be granted the admin role on this SQL Database
server. But for this example, we will select our own Azure AD user
account to be the admin.
Tip It is good practice to set the admin role to a separate Azure AD group that is
created for this SQL Database server. Membership in this group should be carefully
governed.
29
14. Click OK on the Create SQL Database Server blade.
15. We will return to the Create SQL Database blade to continue

configuration.
16. As noted earlier in this chapter, Hyperscale does not support

elastic pools, so specify No when asked if we want to use SQL
elastic pools.
17. Select the Production environment. This affects the default
compute and storage options that are suggested for the database.
However, because we are going to specify Hyperscale, we can’t
accept the defaults anyway.
18. Click the “Configure database” button. This will open the
Configure blade.
19. Set the service tier to “Hyperscale (On-demand scalable storage).”
30
20. The Hardware Configuration option should be set to “Standard-

series (Gen5).”
21. We can leave the vCores option set to 2.
22. Set High-Availability Secondary Replicas to 1 Replica.
23. Specify Yes when asked if you would like to make this database
zone redundant.
24. Click the Apply button.
25. We will return to the Create SQL Database blade again. We will not
change any of the other deployment options, such as Networking
and Security for this example, as we can change most of them
after deployment.
31
26. Click the “Review + create” button.
27. Review the estimated cost per month and scan through the
configuration to confirm we’re configuring what we expected.
There are ways to reduce the estimated cost per month (such
as purchasing reserved capacity), but these will be discussed in
Chapter 16.
Important The Azure SQL Database Hyperscale tier is billed hourly. So, once the
resources are deployed, you’ll begin to be billed. Deleting the database resource
will cause you to stop being billed, but you will be charged for at least one hour.
28. Click the Create button.
29. After a few seconds, our resources will begin to be deployed, and a
deployment progress window will be displayed.
32
30. Once the deployment has been completed, we can click the
sqlhyperscalerevealed01/hyperscaledb resource (or whatever
you called it in your subscription) to be taken directly to the
database.
31. We will be taken to the Overview blade of our new Hyperscale

database.
Congratulations! You have deployed your first Hyperscale database and can begin
to use it. There are other administrative tasks we would typically do from here, such
as granting access to the database and opening network access to our applications
and users, but they will all be covered in later chapters. For now, this is enough to
demonstrate just how easy it is to get a Hyperscale database up and running in Azure.
33
Another random document with
no related content on Scribd:
Gebel the principal constituents of the sudd are the papyrus and the
‘um soof’ reed. Both these plants grow with their roots bedded in the
soil below the shallow water of the lagoons. Strong gales are
prevalent in these latitudes, and these loosen the roots, so that, if the
storms are accompanied by flood, large masses of the plants are set
free, and begin drifting over the lagoons. Quantities of earth remain
clinging to their drifting roots, and thus they are driven backwards
and forwards by the wind. The storms come generally just before the
flood, and thus there is plenty of water for the reeds to float in.
Eventually they are driven, whole acres at a time, into the channel of
the river, and are carried down the stream. But the channel being
very narrow and winding, they soon get caught up, and a block
occurs. New masses come down, and these are sucked by the
stream under the original block, till a dense mass is formed,
sometimes as much as over 20 feet thick, and so solid that a man
can walk over it. If left to themselves, these blocks may last a very
long time, and cause the river to change its course; or else by
increased pressure the block is burst, and a great wave passes
down the river, which sweeps all other blocks away. Years of high
flood are generally followed by a great deal of sudd.
It appears that the conditions on the river between Lake No and
Shambe are much more favourable to blocking by sudd than they
used to be. In 1840 Mehemet Ali sent a scientific expedition under
D’Arnaud to explore the White Nile. At that time the main stream
through the sudd country was much bigger and stronger. No mention
is made of the Bahr el Zeraf at all, which looks as though it was of
much less importance, at any rate. They noticed, however, a number
of openings in the banks between the river and the swamps, some
natural, but some artificial, made by the natives for fishing purposes.
It is plausibly argued by Sir W. Willcocks that these openings were
later widened by the natives to enable them to escape in their
canoes from the slave-dealers, and then by the slave-dealers
themselves, escaping in their turn from Government patrol boats. All
these spills would drain into the Bahr el Zeraf, which gradually
became a navigable stream in its lower part. In 1863 Sir Samuel
Baker ascended the Bahr el Gebel without any difficulty; but in that
year there was a very high flood and a great deal of sudd. Returning
in 1865, Baker found the river north of Lake No considerably
blocked. In 1870 Baker was unable to ascend the Bahr el Gebel with
his expedition to Equatoria, and went by the Bahr el Zeraf. He cut
through the sudd in that stream with prodigious labour, and had
finally to cut a ditch through 2,000 feet of solid clay. Even then the
Bahr Zeraf level was so much below that of the Bahr el Gebel that he
could not get his boats through until he had dammed the Zeraf
behind them so as to lift them up. In 1873 he says he found the
canals much improved by the force of the stream. All this naturally
contributed to weaken the power of the main stream and render it
very liable to sudding.
In 1874, when the river was low, the sudd was cleared away by
Ismail Pasha Ayoub, then Governor-General of the Soudan, and all
through Gordon’s time in Equatoria there was free passage, but the
channel had dwindled very much. The heavy flood of 1878 brought
the sudd down again worse than ever, where it remained until
cleared by Marno in 1880. It was in that year that Gessi, on his way
back from his province, was caught and suffered such hardships in
the sudd on the Bahr el Ghazal. He was only rescued by the
appearance of Marno. Unfortunately, no record has been left of the
methods which Marno employed in the work, but he spoke of it as
quite an easy matter.
Little is known of the state of the sudd during the years of the
Mahdi and the Khalifa; but in 1898 Lord Kitchener found the Bahr el
Gebel blocked by sudd immediately above Lake No; and about the
same time Colonel Martyr, coming from Uganda, was unable to
penetrate more than 20 miles north of Shambe for the same reason.
As soon as the Khalifa had been finally crushed, operations to clear
the channel were immediately undertaken. In the first three months a
length of 80 miles of river had been cleared, including 5 miles of
actual sudd in eleven blocks, besides three more blocks which broke
away of themselves. The blocks that came away of themselves
represented a very large amount of sudd. After one of them had
burst, the floating weed took thirty-six hours to pass a given point.
The effect produced by the sudd in damming up the river is
illustrated by the fact that when the third block, which was nearly 20
feet thick, was removed, the upstream level fell 5 feet in four days,
and all the swamps and lagoons began to drain into the river.
The amount of labour was prodigious. At one place, owing to the
enormous masses of um soof and papyrus that kept pressing into
the river, no less than eleven clearances had to be made in one year.
Five gunboats and 800 dervish prisoners, besides officers and
guards, were employed. Sir W. Garstin gives an interesting
description of the methods by which the sudd was removed:
‘In the first place, the papyrus and reeds on its surface were burnt (curious to
relate, these green reeds burn readily when the marsh is dry), and in a few hours’
time the surface of the sudd was an expanse of blackened stalks and ashes. As
soon as the fire had died down, gangs of men were landed from the steamer and
employed in cutting trenches on the surface of the sudd. These trenches averaged
from 0·60 to 0·80 metre in width, and from 1 to 1·25 metres in depth—i.e., as deep
as the men could work. The surface was thus divided into a number of rectangular
blocks some 3 metres by 4 metres. To these blocks were attached, one by one,
steel hawsers and chains. This done, the steamer downstream went full speed
astern. It invariably took several pulls to detach a block, and in some instances as
many as nine were necessary. Both hawsers and chains kept constantly breaking,
although the former were calculated to stand a strain of 35 tons per square inch,
and the latter as much as 60 tons. As soon as a block was detached from the
mass, it was allowed to float downstream. It was curious to see the green reeds
and papyrus which had been confined beneath it reappear on the surface of the
water. A horrible stench prevailed from the rotting vegetation.’
In 1900-1901 four more blocks were removed. An experiment was

made to break up one of the blocks by means of explosives, but it
was found that the sudd, though very solid, was too elastic, and the
only effect was to make large holes in it and no more. The old
method had to be once more resorted to. By the end of 1901 only 23
miles of the channel remained uncleared, but this proved to be the
most difficult of all. One block was actually 7 miles in length. Portions
of the sudd had rotted, and, sinking to the bottom, completely filled
up the channel, so that there was no stream at all, and it was
impossible to tow pieces away and float them downstream by the
usual process. To get up the river it is still necessary to go round by
a series of lagoons, in which navigation is difficult, and operations
have been suspended for the present.
The sudd in the Bahr el Ghazal was much easier to remove, and
great progress has been made, so that now the whole of that river is
free, and boats can even ascend the Jur River to Wau.
It is very difficult to ascertain the precise effect of the removal of
the sudd on the water-level in Egypt. But it is certain that as each
block was removed a quantity of water drained off the marshes and
helped to diminish the fall of the river in summers of very small
supply. Most of this water, spread out over a large surface, must
otherwise have been evaporated and lost altogether. There can be
no doubt that the improvement of the channel has been a permanent
gain to Egypt of a very substantial kind, to say nothing of the
advantage to the Soudan from the opening up of such an important
line of communication. Those who laboured at the task deserve the
highest praise. The river was so low that all communication with
Khartoum was cut off for several months, and transport of supplies
was always difficult. Besides this, the climate is always unhealthy,
and the mosquitoes at night are almost beyond endurance.
Under present conditions it will require constant care and
watchfulness, especially in years of high flood, to prevent the sudd
from frequently obstructing the river. But if the danger is to be
permanently removed, the main channel must be so much improved
by widening and deepening it that it will carry a greater volume. This
will at the same time prevent the water from being dissipated in the
marshes, and diminish the chances of any obstruction. The
necessity for some work of this kind, if there is to be a reservoir at
Lake Albert or Lake Victoria, has already been referred to. The
clearing of the sudd is only the essential preliminary to the greater
scheme.
One point remains to be noticed. Under the old basin system in
Egypt there could hardly be too high a flood, nor did a low summer
Nile create any extraordinary difficulties when there was so little
summer cultivation. But with perennial irrigation a high flood
becomes a matter of supreme anxiety, and the preservation of its
dykes is the anxious care of every village. On the other hand, all the
schemes for reservoirs aim at increasing the summer supply. If the
Bahr el Gebel was trained so as to bring down more water in
summer, it would also bring down more in flood, though the swamps
would still act as an escape for the waters beyond a certain rise. It
might therefore become a matter of great importance to Egypt to
actually diminish the supply during the flood, especially as year by
year more of the basin land is converted to perennial irrigation.
Regulators at Lakes Victoria and Albert would serve in some degree
for flood protection as well as for storage against summer use. It is
calculated that the complete closing of the outlet of Lake Victoria at
the Ripon Falls would only raise the surface of the lake 20 inches in
a year. But it would be far more effective if some of the flood-waters
of the rivers—e.g., the Blue Nile and the Atbara—which are fed by
the rains of Abyssinia could be intercepted before they reached
Egypt. A large irrigation during the flood and early winter along the
Blue Nile might indeed actually lengthen out the flood in Egypt, whilst
depriving it of danger through excess at any one period.
CHAPTER XIII
THE UNITY OF NILELAND
It is no longer possible to think of our occupation of Egypt as merely

a stepping-stone on the road to India—‘the Englishman reaching far
over to his loved India.’ Still less can it be looked upon solely as a
means for the regeneration of Egypt and the education of her people
till they are able to pass from a state of tutelage and stand securely
by themselves. Certainly, great strides have been made in this
direction. If Egypt were the whole matter we might hope that in time,
but not in one or two generations, a race of native administrators
might rise up, to whom the affairs of that country might safely be left.
But Egypt is only a portion of the great country of the Nile. Looking
southward from Alexandria or Suez, the horizon is only bounded by
the sources of the Nile, and these do not well up at Assouan, as
Herodotus was told. We might hope that the Egyptians would be
capable of managing Egypt; but not the most sanguine enthusiast
could imagine a period of time sufficient to make them capable of
managing the Soudan. A cry of ‘The Soudan for the Soudanese’
would hardly be more ridiculous. The story of the binding of the Nile,
incomplete as that story is at present, makes one thing, at least,
perfectly clear, and that is, that all Nileland is one country. No divided
sovereignty is possible; there must be one firm hand over all.
It would have needed a preternaturally keen eye to perceive that
from the moment we began to patch the old Barrage the occupation
of the whole Valley of the Nile was inevitable. Looking back, it is
easy to see how it all followed in logical sequence. Everything
depended on the Nile. The more Egypt was developed, the greater
grew the need for the regulation of the water. The rulers of Egypt
need have troubled little about the fate of countries divided from
them by so many leagues of rainless desert, but for the link of the all-
important river.
It sounds a far cry from the snows of Ruwenzori, the lakes and
swamps of Equatorial Africa, or the rain-swept hills of Abyssinia, to
the cotton-mills of Lancashire. The Egyptian peasant, lifting water on
to the fields of the Delta, knows that the connection is close enough.
We have our own direct commercial interest in holding the Valley of
the Nile, and Egypt is still on the road to India. Apart, therefore, from
the duties which rest upon us as a civilized Power, we are doubly
responsible for the welfare of the people of the Nileland.
Fifty years ago a distinguished English sailor travelled to
Khartoum and El Obeid, and published an account of his journey in a
little volume entitled ‘A Ride across the Nubian Desert.’ In eloquent
words he describes the wonders of the Nile’s course, and continues:
‘Surely the hand of the Almighty has traced it across the desert that it might be
the union of distant nations. . . . Its mission is not yet accomplished; it is waiting to
be the road to civilize Africa. But it is not an Eastern nation, and not the
Mohammedan religion that can do it; and I am one of those who hope and believe
that Providence will destine it for England. An English Government and a handful
of Englishmen could do it. Cities would rise up at Assouan and Khartoum, whose
influence would be felt over the whole interior. . . . I know, alas! the spirit of the age
is against such thoughts, and there are even men who would wish to abandon our
Empire; but I speak the voice of thousands of Englishmen who, like myself, have
served their country abroad, and who do not love her least, who will never consent
to relinquish an Empire that has been won by the sword, and who think the best
way to preserve it is often by judicious extension.’
On many a stricken field the author of these prophetic words,

Captain Sir William Peel, V.C., the hero of the Naval Brigade in the
Crimea and the Mutiny, proved the sincerity of that love for his
country of which he spoke so warmly. And now, after so many years
and so many vicissitudes of fortune, an English Government and a
handful of Englishmen are grappling with the work on which his heart
was set.
PART II
THE NEW SOUDAN
CHAPTER XIV
THE PAST
As with modern Egypt, so with the modern Soudan: the name of the
Albanian tobacco-seller is writ large upon the pages of her history. In
spite of the ancient connection between Egypt and Ethiopia, in spite
of the dependence of Egypt upon the Soudan for her water, the
warlike tribes of the south remained for more than 1,000 years free
from any attempt at domination by their neighbours. It was Mehemet
Ali who, in the year 1819, laid the foundations of the empire which
reached its furthest limits under the Khedive Ismail, an empire of
which the brief but disastrous history brought nothing but misery and
ruin to the Soudanese, and made the Soudan a name of fear and
trembling to every Egyptian peasant.
About A.D. 700 Arabs of the tribe of Beni Omr, driven out of Arabia,
crossed the Red Sea, and began to settle about Sennar, on the Blue
Nile. By degrees these fugitives, reinforced by other tribes, some
from Arabia direct, some, it is said, by way of Egypt and the
countries further west, swelled to an invading host and permeated
the whole of the Northern Soudan, and the original inhabitants were
largely converted to Islam. In the Sennar region the two principal
negro tribes were the Fung and the Hameg. The conquerors, while
they imposed their language and religion on the conquered, seemed
to have been absorbed into their ranks; for the distinction between
Arab and negro diminished, and the old tribal names reappeared. In
1493 Amara Dunkas, a sheikh of one of the Fung tribes, was
recognised as king of all the Fungs, and conquered all the country
on both sides of the Blue Nile from Khartoum to Fazokhl. The
negroes who remained in the country were merged in the Fungs.
The remainder emigrated to the mountains of Southern Kordofan,
where, under the name of Nubas, they have ever since maintained
themselves in a somewhat precarious independence against the
raids of the Arabs of the plains. About the same time was founded
the Sultanate of Darfur, which in time extended its dominion to the
banks of the Nile. South of these two powers the Shilluks and other
negro tribes continued, as before, generally engaged in some petty
warfare, and regarded as a convenient reservoir of slaves by their
Arab neighbours.
The Fung dynasty lasted 300 years, and attained a very
considerable position. About A.D. 1600 in the reign of Adlan, Sennar
even became famous for learning, and was the resort of many
scientists and philosophers from Cairo and Bagdad. In the reign of
King Baadi, 1719-1758, the fame of the kingdom of Sennar reached
its height. A quarrel arose with Abyssinia on account of some
presents from the King of France which had been intercepted by
Baadi. The Abyssinian King invaded Sennar with a great host, but
met with the most signal defeat. So great an event was heralded
throughout the Mohammedan East. The bazaars of Constantinople
and Delhi were alike filled with the renown of Sennar. Once more
crowds of learned and celebrated men flocked into the country from
every quarter. But it was the last flicker of sunlight before the night
fell. Baadi himself was deposed and exiled on account of his bad
administration. The Hameg tribe, long subject to the Fungs, began to
lift their heads. By 1790 the kingdom of the Fungs had disappeared,
and for thirty years the Hameg continued supreme. Fire and sword
was their sole notion of supremacy; it was no mere theory with them.
The country was utterly given over to anarchy when Mehemet Ali
determined to interfere.
The motives that prompted him were many; possibly, ardent
irrigationist that he was, the desire to secure the upper waters of the
Nile may have been among them; but beyond a doubt, like
Cambyses of old, his principal object was gold. Extraordinary
rumours were current as to an El Dorado in the south. Every officer
and man who took part in the expedition entertained the most
extravagant notions of gold-strewn districts. By means of this, and
also by securing the profitable traffic in slaves, Mehemet hoped to be
able to win sufficient resources to carry out his ambitious schemes in
Asia and Europe. It was also very convenient at the moment to find
employment for his irregular troops. It would be a mistake, however,
to explain his action wholly by such reasons as these. All through his
life ran the dream of posing as a second Napoleon. It is curious to
find that along with the army he sent a number of learned men and
skilled artisans, while it was announced that the object of the
invasion was to introduce the benefits of a regular government of
civilization. Mehemet Ali had closely studied the methods of his great
model.
But of all these designs only one, and that the worst, was destined
to be fulfilled. The slave-trade had always flourished in the Soudan.
The Arab States were founded upon slavery. Along the great Arbain
road, the desert ‘track of the forty days’ from Darfur to Assiout, yearly
caravans containing slaves as well as other merchandise passed
into Egypt; the Nile route served the same purpose, and from the
Red Sea ports there was a constant export trade to Arabia and
Turkey. All this was nothing compared to the dimensions which the
trade assumed under Egyptian rule. It became practically the sole
trade of the country; it reached like a pestilential blight even as far as
the Equator. Bitterly did the Soudan suffer for the Napoleonic ideas
of Mehemet, and bitter, but deserved, was the penalty which Egypt
had to pay for her misgovernment in the end. Even to-day among the
remotest tribes the name of ‘Turk’ stands for loathing and terror.
The army, commanded by Ismail, son of the Viceroy, reached
Sennar without opposition. Thence, accompanied by his brother
Ibrahim, he advanced to Fazokhl in search of the famous gold-mines
in the Beni Shangul. But the gold proved disappointing. Ibrahim
returned to Egypt, destined to win fame as the butcher of the
Peloponnese in the Greek War of Independence. The Arabs rose
against Ismail, and he had to return to defeat them. Unsuccessful in
his quest for gold, he had devoted all his energy to the slave-trade,
but his cruelties and barbarities were too much even for a people
familiar with the Hameg. The local chief at Shendi, appropriately
named El Nemr (the Tiger), invited him to a banquet. While he and
his followers, contrary to the precepts of their own Koran, drank
freely of the forbidden wine, straw was silently piled high about the
house and fired. To a man they perished in the flames.
Meantime, Achmet Bey, the Defterdar, had conquered the
province of Kordofan from the Sultan of Darfur. Hearing of Ismail’s
fate, he marched towards Shendi to avenge him. The story of what
happened, as told by the Egyptians, wears an ugly look. The details
are wanting, but, at any rate, few were left to tell the other side of the
story. At Metemmeh, on the bank of the Nile opposite Shendi, the
people sent messengers to sue for pardon. It was granted. But when
the Defterdar marched into the town a lance was thrown at him. The
pardon was at once rescinded, and a general massacre ensued. El
Nemr himself, however, had fled to Abyssinia. He, at any rate, had
no faith in Egyptian promises. The Defterdar then marched towards
Khartoum, and at Tuti Island another great slaughter took place. It
was a bad beginning. To the native Soudanese the distinction
between the benefits of a regular government of civilization and the
fire and sword of the Hameg must have seemed slight indeed.
To build aright on such foundations would have been difficult for a
nation of born administrators. For the Egyptians it was impossible.
There were among the Egyptian Governors of the Soudan honest
and righteous men, but, amid a crowd of officials bred and trained in
an atmosphere of corruption and slavery, their spasmodic efforts
after good only gave fresh opportunities for evil. Military stations
were established in various parts of the country for the sake of
security, and they became fountains of slave recruits to swell the
ranks of the army. The navigation of the White Nile was declared
free, and it became the favourite route of the slave-traders.
Khartoum, from a village of skins and reeds, rose to be a city of
bricks and the capital of the Soudan, but also a convenient and
central market for a huge slave-trade. The Abyssinians, who
espoused the cause of the Sennar rebels, were beaten back into
their mountains, but the savage methods of warfare only brutalized
and demoralized the victors. It speaks volumes for the barbarous
character of the times that when Adlan, the leader of the
Abyssinians, was captured by Kurshid, reputed the best of the
Governors of the Soudan, he was immediately impaled. The annals
of these years are filled with stories of famine and rebellion, and, to
add to the general desolation, cholera and other diseases constantly
ravaged the country.
But worse was to come. Down to 1853 the southernmost Egyptian
station was only 120 miles south of Khartoum. The annexed
provinces of Kordofan, Sennar, and Kassala (or Taka) groaned under
oppression and tyranny, but the negro inhabitants of the Upper White
Nile and the Bahr el Ghazal were still comparatively unmolested. In
that year the English Consul in the Soudan started a trading
expedition up the river. Other traders followed, who established
stations far up the country. Peaceful trading soon succumbed to the
temptations of the slave-trade. For the sake of protection, it began to
be found necessary to employ bands of armed Arabs or Nubians.
Gradually the European traders disappeared; by 1860 the last of
them had sold their stations to their Arab agents. No greater curse
was ever let loose upon a country than these human locusts, and the
Egyptian Government was directly responsible. Under the shallow
pretence of legitimate commerce, trading monopolies were leased to
these traders in various districts. The fact that the Government had
not a shadow of claim even by right of conquest to the territories
leased was no obstacle. All the country south of Kordofan and Darfur
along the White Nile or the Bahr el Ghazal was regarded as
peculiarly suitable for these nefarious bargains. The Khartoumers, as
they were called, because they had their headquarters in the capital,
established themselves everywhere, and became practically
independent potentates. With their armed bands of brigands they
raided the native tribes, and even used them to fight against each
other. Only the Dinkas, protected by the impenetrable marshes of the
sudd region, and the powerful and warlike Azande, or Niam-Niam, in
the south, were able to maintain themselves. But the Bongo, a
numerous and peaceful agricultural people, were easily reduced.
The fact that they had attained a higher civilization than their
neighbours (for they smelted the iron found in their swamps with
furnaces of clay and rude bellows, and worked it with stone
hammers on anvils of granite, made pottery, and even had some
acquaintance with surgery) only made them the more valuable in the
slave-market. The Jur, Dembo, and Golo tribes were likewise among
the principal sufferers. Anarchy is but a mild term for the condition of
affairs.
Some of these unhappy victims may have heard the news on their
way to the northern slave-market that slavery was abolished in the
Soudan. If so, it cannot have done much to sweeten their bondage
or to heal the strokes of the lash, yet a viceregal decree to that effect
had been solemnly promulgated at Berber in 1857. It was
characteristic of many of the descendants of Mehemet Ali that they
inherited great part of his intellectual vigour and wide sweep of
imagination without any of his executive capacity. Said Pasha, who
became Viceroy in 1854, visited the Soudan and clearly recognised
the failure of his foreign empire. A large force had to be maintained
to screw exorbitant demands out of a discontented population.
Agriculture was depressed, and every other industry was perishing
under a system of taxation vicious in itself, and collected by methods
which might have made a Verres blush. He determined to evacuate
the country. But the burden of the Soudan, so lightly taken up in
greed of gain, was not to be so lightly laid aside. Egypt was now
holding a wolf by the ears. The officials who battened on the ruin of
the country opposed a strenuous resistance. Things had come to
such a pass that the sheikhs and notables of the provinces
themselves feared that the withdrawal of one devil would be followed
by the entry of many. Said contented himself with reorganizing the
government and announcing a number of reforms of a drastic and
far-reaching nature, and then returned to Egypt. It was the first of
many reorganizations and many reforms, all of which were as
effective as the decree for the abolition of slavery. The plan of much
talking and little doing became a fixed principle of Soudan policy.
The story of the tax on sakiehs (water-wheels) affords a good
illustration of Egyptian methods. One of Said’s reforms was to fix this
tax at 200 piastres per annum. In less than nine years it had risen to
500 piastres. Jaaffar Pasha, who finally raised it to this extent,
declared openly that he fixed it at that rate in order to see how much
the peasants would really pay, and he hoped after a three years’ trial
to be able to arrive at a just assessment. It was not a very scientific
plan of taxation in any case, but, unfortunately, Jaaffar was removed
before the scheme had time to work out, and his successors,
absolutely indifferent to his motives, retained the tax, and even
further increased it. It was calculated that on average land the tax
often far exceeded the net returns for one sakieh. Even a ruined
wheel was liable to the full amount, and if an owner returned to it
after an interval he was saddled with the whole of the arrears. On the
same principle taxes continued to be charged on land and trees that
had long since been carried away by the floods. The natural results
followed. Many cultivators were ruined and reduced to beggary,
others fled the country, and much land went out of cultivation. In
1881 more than 2,000 sakiehs were lying derelict in Berber and
Dongola.
By the time Ismail Pasha came to the throne in 1863 it had
become abundantly clear that the Egyptians were unfit to govern the
Soudan. It looked as though in a few years the whole country would
have become a wilderness, totally uninhabited save for a few
wanderers, whose sole occupation would be selling each other into
slavery. And yet the next few years witnessed an enormous
extension of the Egyptian Empire, and Ismail himself enjoyed, until
the bubble burst, a great reputation as a genuine and whole-hearted
reformer. Nor was that reputation wholly undeserved. Strange
compound that he was of vast ambitions but changeable resolution,
of far-reaching sagacity but reckless carelessness, a Westerner in
the conception of his ideals but an Oriental in every sense in his
pursuit of them, he proved himself in his treatment of the Soudan, as
in other spheres, to possess many of the elements of greatness. If
he failed, it was partly because the evil was beyond cure: the
impending catastrophe was too great to be averted. His employment
of Baker and Gordon and other Europeans showed that he realized
the incapacity of Egypt to perform the task by herself. That was in
itself a great step forward; undoubtedly it staved off for a little the day
of retribution. His eager support of the project of a railway to
Khartoum, first mooted by his predecessor, Said, showed a sound
appreciation of the position, though his ineffective attempts to carry it
out showed his weakness as clearly. But the whole hierarchy of
Egyptian officialdom was rotten to the core. The best of rulers
without good ministers is predestined to failure.
To add to a falling house must always be a desperate remedy. No
other course seemed open to Ismail, if he was really to cope with the
slave-trade. So long as the basin of the Upper Nile remained in the
hands of the ‘Khartoumers,’ the sources of the traffic flowed as
briskly as ever, and at the same time the Red Sea ports afforded
every facility for export. Accordingly, in 1866 Ismail purchased the
districts of Suakin and Massowah from the Turks by an increase of
tribute. In 1869 he took a still more important step, and determined
to annex the whole basin of the Nile. He invested Sir S. Baker with
absolute and despotic powers over the whole country south of
Gondokoro. No better choice could have been made. An
administrator of the best type, energetic and high-minded, Baker was
also no stranger to the scene of his mission. He had already in 1861
conducted an expedition up the White Nile to join hands with Speke
and Grant in their investigations of the sources of the Nile, and in
1864 he had discovered the Albert Nyanza.
A strong man was needed. The Khedive seemed in earnest, but
he was occupied with the Suez Canal and other matters nearer
home. His representatives in Khartoum took quite another view; it
was the custom of the Soudan Government to take away with one
hand what it gave with the other. Baker’s appointment bore the
ominous date of April 1, and the fact may well have recurred to him
when, on arriving at Khartoum towards the close of the year, he
discovered that the territory he was sent to annex had already been
leased by the Governor-General to a couple of notorious slave-
dealers. Every conceivable obstacle was put in his way by the
officials. But, in spite of all opposition, he organized his expedition,
and after a journey of incredible difficulty and labour, for the real
channel of the river was blocked by sudd, he reached Gondokoro in
May, 1871, and formally annexed it as ‘Ismailia.’ Next year he
passed south, and proclaimed Unyoro an Egyptian province,
organized a number of military posts, and entered into friendly
relations with M’tesa, King of Uganda. For the time the slave-traffic in
these new provinces was crushed. In 1873 Baker returned to Cairo
with a record of successful work behind him, which must have
astonished no one more than the Khedive himself.
But once the strong hand was removed, the stone which had
been heaved uphill with so much labour rolled swiftly down again.
Less than a year elapsed between the departure of Baker and the
arrival of Colonel Gordon, on his appointment as Governor-General
of Equatoria. Even in that short time the Egyptian occupation had
become merely nominal. Two posts only were held, Gondokoro and
Fatiko. Three large slave-trading stations were in full swing on the
Bahr el Zeraf alone, whilst on the Bahr el Ghazal the notorious
Zubehr had established himself as a practically independent
potentate, and was even preparing on his own account an invasion
of Darfur. The situation called forth Gordon’s fullest energies. Never
did he perform better work than during his three years in Equatoria.
As far as it could be done under Egyptian supremacy, he checked
the slave-trade and laid the foundations of good government. The
country was organized and divided into districts with proper
garrisons both along the Sobat and the White Nile. The tribes were
peaceful and contented. Communication was established with the
great lakes; Lake Albert Nyanza was for the first time
circumnavigated. A treaty was made with M’tesa, King of Uganda,
recognising his independence, and Emin Bey was sent to represent
Egypt at his Court. In 1876 Gordon returned to England.
In Egypt, meantime, the Khedive’s reckless extravagance was
fast hurrying him to disaster. But the more involved he became, the
more he extended his ambitions, like a ruined spendthrift who must
keep up his credit at any cost. Extension of his Empire became a
mania. After Equatoria came the turn of Darfur in 1874. Darfur had
maintained its independence for over 400 years under an unbroken
line of Sultans. One of them, Abd-el-Rahman the Just, had entered
into correspondence with Napoleon during his occupation of Egypt,
and congratulated him upon his defeat of the Mamelukes. Napoleon
replied in a remarkable letter:
‘To the Sultan of Darfur, 12 Messidor, Year VII. In the Name of God,
compassionate and merciful; there is no other God but God! To the Sultan of
Darfur, Abd-el-Rahman.
‘I have received your letter, and understand its purport. When your caravan
arrived I was absent in Syria punishing and destroying my enemies. I pray you
send me by the first caravan 2,000 black slaves, over sixteen years of age, healthy
and strong. I will buy them from you. Order your caravan to come immediately,
without delay. I have given orders for its protection all along the route.
‘Bonaparte, ‘Commander-
in-Chief.’
Many motives combined to make Ismail desire the annexation of

the country. There were longstanding frontier grievances. Its
commerce and slave-trade were still considerable, and Ismail hoped
to profit by the one as well as to suppress the other. The copper-
mines of Hofrat-en-Nahas in Southern Darfur were also a powerful
attraction in view of his failing treasury. They were reported to be
extraordinarily rich, with veins standing 2 feet out of the ground. And,
since Zubehr could not be prevented from his proposed expedition,
the only course seemed to be to join him in the conquest.
Accordingly, an expedition was despatched from the north, while
Zubehr co-operated from the south. The Sultan and two of his sons
were killed in battle, and another troublesome province was added to
the Khedive’s dominions. Zubehr was made a Pasha, but was
refused the governorship, which he claimed as his right. For a
moment he seemed inclined to assert his independence, but in the
end he rashly determined to press his case in person at Cairo,
leaving his son Suleiman to fill his place in his absence.
The same year saw the annexation of Harrar at the request of the
Mohammedans in that country. Raouf Pasha, who had been left in
charge at Gondokoro after Baker’s departure, was sent for that
purpose. He showed that he had learnt but little wisdom or mercy
from his association with Baker and Gordon, for he commenced his
administration by strangling the late Sultan, a wholly unnecessary
act. Egyptian territory had been extending down the Red Sea coast
for some years previously, at the expense of Abyssinia. Little was
gained, except some friction with the King of Abyssinia, for the
occupation was generally quite nominal, and the tributes imposed by
Egypt were seldom or never paid. Still, Egypt now possessed the
coast-line as far as the Straits of Bab-el-Mandeb, and the purchase
of the port of Zeila from Turkey in 1875 extended her possessions to
Cape Guardafui and beyond, and consolidated her position, such as
it was, in Harrar, and what is now Somaliland. But even this did not
satisfy the Khedive.
Gordon had clearly perceived that it was impossible to properly
control the Equatorial provinces without an outlet to the Indian
Ocean, to replace the long and precarious line of communication by
the Nile. He therefore advised the Khedive to occupy Mombasa from
the sea, while he himself co-operated from inland by way of the
Victoria Nyanza. Although the difficult nature of the country and the
inferior quality of his troops soon convinced Gordon that it was
impossible for him to carry out his part in the project, a naval
expedition, known as the Juba River Expedition, set out in 1875
under the command of McKillop Pasha. Missing the mouth of the
Juba River, which had been selected by the Khedive as their
objective, without any great knowledge of the geography of these
regions, they ran further south, but encroached on the territory of the
Sultan of Zanzibar. At the instance of Great Britain the expedition
was given up, but no objection was raised to the recognition of the
Khedive’s authority as far south as the tenth degree of latitude.
It was not long before the folly of all this extravagant expansion
began to appear. Abyssinia had had many causes of quarrel with
Egypt, and, in fact, the relations between the two countries had
consisted of a state of intermittent war or at best armed neutrality
since the time of Mehemet Ali. But the purchase of Zeila thoroughly
alarmed King John, and he took steps to protect his rights. War
followed, disastrous to Egypt. A first army under Arendrup, a Dane,
was, after a few preliminary successes, totally annihilated. A second
was hastily fitted out and despatched. It was a model of all an army
should not be, and had not King John been diverted by the fear of
his rebellious vassal, Menelik, it would no doubt have suffered the
fate of the first. As it was, it managed to return to Massowah after
two or three months’ tedious and inglorious campaigning and one
severe defeat.
The falling house had been extended in every direction, but it was
falling still. The Abyssinian trouble was not the only sign of
weakness. The internal condition of the provinces was as bad as
ever; the whole country was restless and disturbed; the feebleness
of the Government was increased by the huge distances over which
its garrisons were scattered; the slave-trade, openly favoured by the
officials whose duty it was to suppress it, was recovering from the
blows which had been dealt it. One more heroic effort was made to
set things right. Gordon was recalled to Egypt and made Governor-
General of the whole Soudan, including Equatoria and the Red Sea
provinces. He was specially charged with the duty of settling matters
with Abyssinia, of suppressing the slave-trade, and of improving
communications.
It was with the utmost reluctance that Gordon returned to the
Soudan. Under existing conditions his task was a hopeless one, and
he knew it. His letters show how clearly he foresaw the coming
catastrophe. He was aware that, while the Egyptian Government
was concluding an anti-slavery convention with England, it was at
the same time intriguing almost openly with Zubehr, the prince of
slave-dealers. Less than half-hearted support was to be expected
from Cairo. At the very moment that he needed them most, great
part of his troops were withdrawn to serve in the Russo-Turkish War.
Immediately on assuming the reins of government he found himself
confronted by a serious rebellion in Darfur; at the same time the
slave-dealers in the south were gathering in force under the
leadership of Suleiman, Zubehr’s son. But Gordon faced the peril
undismayed. His activity was almost superhuman. Hastily patching
up a temporary arrangement on the Abyssinian frontier, he travelled
to Khartoum by way of Kassala, Gedaref, and Sennar. Here he spent
some time in carrying out a number of reforms, and in May set out to
deal with the rebellion in Darfur. Darfur had had its first experience of
Egyptian rule, and Harûn, a member of the deposed royal house,
had taken advantage of the general discontent. There flocked also to
his standard the nomad Arab tribes, who had stood aloof when
Darfur was first conquered, but now saw their hereditary trade
threatened. But Gordon in a few months had drawn together his
scattered garrisons and scattered the rebels by a display of force. By
the almost unsupported exercise of his personal influence he next
dispersed the combination of slave-dealers under Suleiman, and by
the end of the year he was back again at Khartoum, after another
visit to the Abyssinian frontier and a round by Suakin and Berber.

Azure SQL Hyperscale Revealed High Performance Scalable Solutions For Critical Data Workloads 1St Edition Zoran Barac Full Chapter

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Azure SQL Hyperscale Revealed High Performance Scalable Solutions For Critical Data Workloads 1St Edition Zoran Barac Full Chapter

Uploaded by

Copyright:

Available Formats

Azure SQL Hyperscale Revealed:

High-performance Scalable Solutions

ISBN-13 (pbk): 978-1-4842-9224-2 ISBN-13 (electronic): 978-1-4842-9225-9

Copyright © 2023 by Zoran Barać and Daniel Scott-Raynsford

About the Technical Reviewers����������������������������������������������������������������������������� xiii

Chapter 2: Azure SQL Hyperscale Architecture Concepts and Foundations����������� 37

Part II: Planning and Deployment����������������������������������������������������������������� 75

Chapter 4: Deploying a Highly Available Hyperscale Database

Chapter 5: Administering a Hyperscale Database in a Virtual Network

Chapter 7: Enabling Geo-replication for Disaster Recovery��������������������������������� 187

Chapter 8: Configuring Security Features and Enabling Diagnostic

Chapter 9: Deploying Azure SQL DB Hyperscale Using PowerShell���������������������� 213

Chapter 12: Testing Hyperscale Database Performance Against Other

Part III: Operation and Management����������������������������������������������������������� 339

Chapter 14: Backup, Restore, and Disaster Recovery������������������������������������������ 361

Chapter 15: Security and Updating����������������������������������������������������������������������� 381

Chapter 16: Managing Costs�������������������������������������������������������������������������������� 399

Part IV: Migration��������������������������������������������������������������������������������������� 407

Chapter 18: Migrating to Hyperscale�������������������������������������������������������������������� 419

Chapter 19: Reverse Migrating Away from Hyperscale���������������������������������������� 449

Chapter 20: Conclusion����������������������������������������������������������������������������������������� 459

Daniel Scott-Raynsford is a partner technology strategist

Vitor Fava has earned the title of Most Valuable Professional

At its core, Hyperscale helps us address these changing requirements, without

The Basics of Azure SQL

• As infrastructure as a service (IaaS) using SQL Server on Azure VMs

Figure 1-1. Continuum of cost and administration of different hosting models

Azure SQL Platform as a Service

• Azure SQL Database

• Azure SQL Managed Instance

Table 1-1. Azure SQL PaaS Deployment Options

Purchasing Models and Service Tiers

• Basic: Use for less demanding workloads: up to 5 DTU, up to 2GB

• Standard: Use for workloads with typical requirements: up to 3000

• Premium: Use for I/O-intensive workloads: up to 4000 DTUs, up to

The vCore purchasing model represents a choice of specific virtual hardware

• Azure SQL DB: 2–128 vCores, up to 625GB memory, and up to

• Azure SQL MI: 4–80 vCores, Standard-series 5.1GB RAM/vCore,

• Azure SQL DB Serverless: 0.5–80 vCores, up to 240GB memory,

• Azure SQL DB: 2–128 vCores, up to 625GB memory, and up to

• Azure SQL MI: 4–80 vCores, Standard-series 5.1GB RAM/vCore

• Standard-series (Gen5): 2–80 vCores, up to 415GB memory, and

• Premium-series: 2–128 vCores, up to 625GB memory, and up to

• Premium-series memory-optimized: 2–128 vCores, up to 830GB

• DC-series (enables confidential computing): 2–8 vCores, up to

Availability Models and Redundancy

• Standard: Separates compute and storage tiers. It relies on the

• Premium: Like the Always On availability option for VMs. It relies on

• Local redundancy: All Azure SQL PaaS deployments offer local

• Zone redundancy: This replicates a database across multiple

• Geo-redundancy: There are multiple ways to achieve geo-redundancy

Tip Zone-redundant configuration is available only for Azure SQL Database

• Standard availability model: DTU purchasing model Basic and

• Premium availability model: DTU purchasing model Premium

 tandard Availability Model: Locally

Figure 1-5. Azure SQL PaaS Standard availability model architecture

General Purpose Service Tier: Zone-­Redundant Availability

 remium and Business Critical Service Tier: Locally

Figure 1-7. Azure SQL PaaS Premium availability model architecture

 remium and Business Critical Service Tier:

confined to a single AZ rather than an entire region. High availability is accomplished

 rotecting Against Regional Outages Using Failover

The Hyperscale Service Tier

About the Technical Reviewers�� xiii

Chapter 2: Azure SQL Hyperscale Architecture Concepts and Foundations�� 37

Part II: Planning and Deployment�� 75

Chapter 4: Deploying a Highly Available Hyperscale Database

Chapter 5: Administering a Hyperscale Database in a Virtual Network

Chapter 7: Enabling Geo-replication for Disaster Recovery�� 187

Chapter 8: Configuring Security Features and Enabling Diagnostic

Chapter 9: Deploying Azure SQL DB Hyperscale Using PowerShell�� 213

Chapter 12: Testing Hyperscale Database Performance Against Other

Part III: Operation and Management�� 339

Chapter 14: Backup, Restore, and Disaster Recovery�� 361

Chapter 15: Security and Updating�� 381

Chapter 16: Managing Costs�� 399

Part IV: Migration�� 407

Chapter 18: Migrating to Hyperscale�� 419

Chapter 19: Reverse Migrating Away from Hyperscale�� 449

Chapter 20: Conclusion�� 459

The Basics of Azure SQL

Azure SQL Platform as a Service

Purchasing Models and Service Tiers

Availability Models and Redundancy

tandard Availability Model: Locally

General Purpose Service Tier: Zone-Redundant Availability

remium and Business Critical Service Tier: Locally

remium and Business Critical Service Tier:

rotecting Against Regional Outages Using Failover

The Hyperscale Service Tier

Hyperscale Architecture Overview

Deploying Your First Hyperscale Database