Добри практики при мигриране на on-premise инфраструктура към облака

Автор: Евгени Дюлгеров

В тази статия ще разгледаме особеностите на мигрирането на ключова инфраструктура от настолни (on-premise) сървъри в сървъри, намиращи се в Azure облака. Ще бъдат разгледани добри практики при извършване на този тип миграция. А ти имаш възможност да се докоснеш до работата с облака на практика по време на започващия скоро курс Azure Essentials – февруари 2023.

Фази на мигрирането

Мигрирането на инфраструктура от настолни сървъри към Azure следва стандартна постъпкова методология за мигриране на приложения и данни. Тази методология включва следните стъпки – фаза „Анализ”, фаза „Мигриране на приложения”, фаза „Мигриране на данни”, фаза „Тестване и оптимизация” и фаза „Операции и Управление”, показани на схемата по-долу.

По-долу ще разгледаме всяка от тези фази и добрите практики свързани с тях.

Фаза „Анализ”

Целта на тази фаза е да разберем бизнес изискванията, поради които извършваме миграция от настолни сървъри към облачни сървъри. След като установим бизнес нуждите, трябва да анализираме архитектурата на текущите бизнес решения и да открием основните разлики между бизнес решенията и предоставените от Microsoft Azure облачни услуги, както и да преценим дали не трябва да променим дизайна и архитектурата на съществуващите бизнес решения, така че те да могат да бъдат мигрирани към облачни бизнес решения.

Дефиниране на бизнес изискванията

Можем да си зададем множество въпроси породени от възможните бизнес сценарии, които могат да бъдат породени от едно Windows Azure бизнес решение:

1. Дали целим привличане на нови клиенти и потребители?
2. Дали приложението отговаря на регулациите за съхранение на данни, когато данните се съхраняват в облака?
3. Кои от приложенията, част от съществуващата бизнес архитектура, са по-лесни за мигриране към облака?
4. Коя облачна услуга е по-подходяща за нашите приложения и бази данни – Azure Cloud Services или Azure Virtual Machines?

Определяне на разминаванията във функционалностите

Тук трябва да си зададем въпроса дали можем да мигрираме съществуващите приложения в облака без каквито и да е промени. Например Azure SQL Database услугата не поддържа всички функционалности на on-premise SQL Server решението и трябва да вземем това предвид.

Подготвяне на план за производителност и скалируемост

Много приложения биват разработени с тясна взаимовръзка между приложната логика и базите данни. За този тип приложения трябва да отделим приложната логика от компонентите, свързани с базите данни, за да позволим на приложенията да работят и да скалират по-добре в облака.

Ако приложенията обработват огромно количество данни, е добра практика да използваме механизъм за кеширане като Azure Caching Service, така че да намалим заявките между приложението и базите данни.

Ако пък приложенията, които мигрираме, извършват сложни трансакционни операции, то при мигриране към SQL Database трябва да вземем предвид, че една SQL Database инстанция в облака може да поеме ограничен брой трансакции в секунда и да има ограничена максимална големина на базите данни.

Например Azure SQL Database услугата не поддържа всички функционалности на on-premise SQL Server решението. Когато работим с огромни бази данни или висок обем от трансакции, трябва да помислим как да имплементираме скалируема архитектура, използваща множество бази данни, или да използваме SQL Database Federations, за да разделим данните в смислово логически и автономни бази данни, които могат да скалират независимо една от друга.

Например като използваме архитектурен шаблон „Фрагментиране на данните”.

В примера данните са разделени в 3 отделни бази данни според цената на артикулите (база данни 1 – цена от 0 до 49 лв., база данни 2 – цена от 50 до 99 лв. и база данни 3 – цена над 100 лв.).

Фаза „Мигриране на приложенията”

Веднъж щом решим да мигрираме бизнес решенията си към облака е добре да започнем с пилотна версия с минимално количество данни, за да демонстрираме концепцията от необходимост за мигриране към облака. Първо имплементираме необходимите промени в кода на приложенията, за да отговорим на необходимите изисквания за миграция в облака, след което можем да компилираме и качим кода, заедно с необходимите роли в Azure.

Фаза „Мигриране на данните”

Трябва да извършим мигриране на релационните данни от настолното SQL Server решение към облачното решение SQL Database, а също така и да мигрираме нерелационните данни към хранилища за данни като Blog Storage или Table Storage.

Фаза „Тестване и оптимизация”

След като мигрираме приложенията и данните в облака, трябва да направим функционални тестове и тестове за производителност. С други думи – тестваме дали бизнес решението ни в облака работи според очакваното и дали резултатите, които получаваме от работата му, са по-добри от тези които получаваме от настолното бизнес решение. След това разрешаваме възникнали проблеми, свързани с функционалност, производителност, скалируемост и други.

Фаза „Операции и управление”

След фаза тестване и оптимизация, трябва да настроим следене на работата на приложението и да водим детайлен лог за операциите в него, използвайки Windows Azure Diagnostics. Тази услуга ни позволява да събираме диагностични данни от приложения, които се изпълняват в Azure. Тези диагностични данни можем да използваме за разрешаване на проблеми, свързани с функционалност, производителност, използване на ресурси, анализ на трафика и други.

Ако трябва да синхронизираме данни между настолно SQL Server решение и облачно SQL Database решение, е добра практика да настроим и конфигурираме SQL Data Sync. Също така е добра практика да имаме и план за възстановяване на данните, в случай на потребителски грешки или проблеми, свързани с инфраструктурата.

Планиране на миграция

Когато започваме планирането на миграция, трябва да вземем предвид няколко ключови фактора като цена, бизнес и технически изисквания, срокове, както и необходимото по време на миграцията тестване.

Планиране според цената

Оценяването на цената на едно Azure бизнес решение зависи от много фактори като мрежово натоварване, входно-изходни операции на бизнес решението, обем на обработените данни. За целта е добре да използваш ценовият калкулатор на Azure.

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

Добра практика е да направим тестване на производителността и да планираме капацитета на ресурсите, които ще са ни необходими в бъдеще.

Извършване на анализ и дизайн

Във фаза „Анализ и Дизайн” трябва да идентифицираме приложенията, които планираме да мигрираме към Azure, като за целта трябва да планираме архитектурния дизайн на облачното бизнес решение. Ключови елементи на планирането са:

1. Идентифициране на трудности – този списък включва елементи от настолната архитектура, които може да се наложи да бъдат преработени:
   • Компоненти на приложението, които имат ниска производителност – например ако имаме SQL заявки, които не работят според очакваното, е хубаво да ги преработим преди да направим миграция.
   • Определяне на възможности за еластична скалируемост – да проверим кои компоненти могат да бъдат отделени като самостоятелни функционални единици и могат да бъдат скалирани независимо един от друг.
   • Определяне на прекомерни натоварвания – да установим периодите на повишено натоварване на настолните бизнес приложения и да планираме как облачните ни приложения ще скалират, за да поемат повишения трафик.
2. Идентифициране на технически изисквания – трябва да определим изискванията за всеки компонент на приложението в периодите му на високо и ниско натоварване и да планираме как да скалираме всеки копонент. Следният списък включва някои технически изисквания:
   • Използване на релационно хранилище – трябва да проверим данните, съхранявани в релационните бази данни. Данните, които са трансакционни и релационни трябва да се мигрират към релационно облачно хранилище за данни като Azure SQL Database или SQL Server, работещ на Azure виртуална машина.
   • Избиране на правилното релационно хранилище – трябва да се вземат предвид редица фактори, като размера на базите данни, броят на базите данни, дали имаме заявки между повече от една бази данни, дали ще имаме репликация на данните, как ще защитим достъпа до базите данни и др.
3. Функционална декомпозиция на приложението – трябва да определим къде приложението може да бъде разделено на самостоятелни функционални единици, така че да работи под различни Azure роли или виртуални машини.

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

След като дефинираме обхвата на миграцията, количеството работа за всяка стъпка става по-ясно. Трябва да прегледаме всеки компонент на приложението и да определим време и ресурси необходими за разработка, тестване и миграция. Когато декомпозираме приложението, добра практика е да разработим компонентите паралелно един на друг, от гледна точка на оптимизиране на сроковете по проекта, а и с цел да изработим еластично скалируеми компоненти.

Планиране на тестването

Всеки план за миграция трябва да включва функционално тестване и тестване за натоварване. Хубаво е да имаме автоматизирани скриптове за тестване.

Планиране на необходимите ресурси

Когато дефинираме бизнес и техническите изисквания, трябва да идентифицираме ресурсите, необходими за изпълнението на миграцията успешно. Трябва да се фокусираме върху следните 3 зони:

1. Персонал – трябва да подберем хора с правилните умения, за да извършим успешна миграция на приложението.
2. Инструменти – трябва да идентифицираме какви инструменти са ни необходими за разработка, тестване и качване на разработеното приложение в Azure.
3. Консултиране – може да ни потрябва допълнителна екпертиза за миграцията на нашето приложение, от външен консултант.

Планиране на управлението на приложението в Azure

За малки приложения Windows Azure Management порталът може да бъде достатъчен за управление на мигрирани архитектури. Той ни позволява да управляваме миграции и приложения, включително да променяме броя на ролите на инстанциите и да управляваме инстанциите на базите данни.

За по-големи приложения Azure е предоставило REST API, за да можем да управляваме приложенията си и виртуалните си машини програмно.

Имплементиране на план за миграция

Добра практика след мигрирането на приложението към Azure е да изпълним функционални тестове и тестове за производителност, за да проверим дали мигрираното приложение работи според изискванията.

Настройка на тестовете за валидиране

Можем да използваме следните подходи, за да тестваме дали приложението, което е мигрирано, работи според очакванията:

1. Windows Azure Tools for Visual Studio – можем да разработим приложението и след това да изпълним и тестваме приложението локално, използвайки compute и storage емулатори, предоставени от Windows Azure Tools.
2. SQL Server Data Tools – инструменти, предоставящи ни среда за разработка в рамките на Visual Studio, в която можем да създаваме бази данни, да създаваме и променяме обекти в базите данни, както и самите данни, да изпълняваме заявки и други. Позволява ни да тестваме базите си данни локално или използвайки Windows Azure SQL Database решение.
3. Automated Test Framework – много съществуващи приложения вече разполагат с автоматизирани платформи за тестване, които могат да бъдат използвани за проверка дали всички компоненти и функции на приложението работят според очакваното.
4. Visual Studio Load Testing – ако приложението не разполага със съществуваща платформа за автоматизирано тестване, можем да си създадем такава и да използваме Visual Studio Load Testing, за да направим симулация на тестване с няколко различни потребителя.

Синхронизиране на базите данни

Може да отнеме часове или дни, за да копираме огромна база данни от настолните сървъри на сървъри в облака. Понеже не искаме приложението ни да не работи през това време, трябва внимателно да анализираме базата данни на настолното приложение и да преценим кои таблици съдържат статични данни и кои таблици съдържат данни, които предполагаме, че ще се променят по време на операцията по копиране на базата.

Ако имаме съмнения дали дадена таблица е статична, е хубаво да разработим скриптове, които да мигрират промените по данните, които са възникнали по време на операцията по копиране, докато настолното приложение е работило. Можем да използваме следните методи за синхронизация на данните:

1. Windows Azure SQL Data Sync – предоставя възможности за синхронизация на Azure SQL бази данни, както и между on-premise база данни и Azure SQL база данни. За всяка синхронизирана таблица, Azure SQL Data Sync добавя таблица за следене на промените.
2. Extract, Transform и Load (ETL) процес – можем да създадем ETL задача, която да прехвърли променените данни от настолната база данни към Azure средата.
3. Съхраняване и възстановяване на данните – целта на създаване на backup на дадени бази данни е за да се възстановим от загуба на данни, причинена от административни грешки, грешки, свързани с приложенията или други. Създаването на backup и възстановяването на данните е различно за настолно SQL Server решение и за Azure SQL Database решение, затова трябва да имаме подходяща стратегия за backup и възстановяване на данните.

Мигриране на приложението към Azure

Когато правим миграция на приложение към Windows Azure можем да следваме следните два подхода:

1. Паралелно изпълнение на приложенията – с този подход приложението може да работи паралелно на настолните сървъри, както и в облака. Това ни позволява да извършим тестове върху реални данни на приложението в Azure, преди приложението да стане напълно зависимо от облачните услуги. Тестовете ни трябва да включват функционални тестове, тестове на производителността и тестове на скалируемостта. След като завършим тестването на новата система в Azure, можем да направим финална миграция на данните и да спрем използването на настолното бизнес решение.
2. Спиране и мигриране – този подход е необходим, когато всички данни трябва да бъдат синхронизирани преди да започнем работа с бизнес решението в Azure. Използвайки този подход, всички функционални тестове и тестове за производителност трябва да се извършат първо в облака. Тогава настройваме настолното бизнес решение да копира данните в облачната среда, използвайки някой от по-горе описаните методи за миграция.

Добри практики при мигриране на виртуални машини

На диаграмата по-долу можем да видим, че Azure виртуалните машини могат лесно да позволят на клиентите да разширят техните мрежови среди в облака. Това позволява много по-лесно да мигрираме съществуващи бизнес приложения в облака, а също така можем по-лесно да поддържаме хибридни приложения, които работят както на настолни сървъри, така и в облачни сървъри. Можем да управляваме наши собствени виртуални мрежи в облака и, използвайки облачни маршрутизатори, да направим връзка между настолната среда и Azure.

Azure виртуалните машини са подходящи за следните типове приложения:

1. Съществуващи приложения за бази данни, които не са от ключово значение за бизнеса.
2. Нови приложения за бази данни, които ще бъдат качени на SQL Server инстанции в Azure виртуални машини, в случай че Azure SQL Database услугата не предоставя необходимите за тези приложения функционалности.
3. Backup решения за настолни приложения за бази данни.
4. Бизнес решения, които трябва да скалират при високо натоварване.

Azure ни позволява да управляваме нашите приложения и виртуални машини, използвайки REST API и PowerShell команди.

Критерии за избиране между SQL Server и Azure SQL Database

Можем да използваме следните критерии, когато избираме дали да използваме SQL Server база данни на Azure виртуална машина или Azure SQL Database услугата:

1. За нови приложения за бази данни – можем да използваме както Azure SQL Database услугата, така и SQL Server инстанция във виртуална машина, освен в случаите, в които Azure SQL Database не поддържа всички необходими функционалности. В този случай е препоръчително да използваме SQL Server инстанция във виртуална машина.
2. За съществуващи приложения за бази данни – можем да качим съществуващи виртуални машини в Azure или да създадем нови инстанции на виртуалните машини с инсталирани на тях SQL Server решения и да създадем deployment пакети, използвайки SQL Server Data Tools и SQL Server Management Studio. След което, използвайки тези пакети, можем да извършим миграция на приложенията за бази данни.

Подготвяне на схемата на базите данни и данните за миграция

Когато мигрираме базите данни и данните от SQL Server към Azure виртуална машина, трябва да следваме следните стъпки:

1. Да подготвим файл със схемата и данните от базата, използвайки методи като DAC, backup и restore, или detach и attach.
2. Можем да компресираме и криптираме файловете си преди да ги прехвърлим в Azure.
3. Да прехвърлим схемата, данните и лог файловете на базата в Azure.
4. Да заредим файла със схемата и данните в SQL Server инстанцията на облачната виртуална машина.
5. Да пресъздадем всякакви метаданни, които не са могли да бъдат прехвърлени.

Добри практики при мигриране към облачни услуги

При мигриране на съществуващи бизнес приложения към Azure трябва:

1. Да добавим специфични за Azure конфигурации и необходимия код за използване на тези конфигурации.
2. Да преработим съществуващите си бизнес решения като Azure приложения.
3. Да качим бизнес решенията си на облачни услуги, работещи на Azure виртуални машини.

Облачните услуги включват както кода на нашите приложения, така и техните конфигурации за Azure. Разработчиците трябва да вземат предвид качествените характеристики на архитектурата на приложенията като „достъпност”, „скалируемост”, „надеждност” и „сигурност”. Също така трябва да вземат предвид договорите за поддръжка, да планират капацитета на приложенията, клиентското таксуване, одитирането на приложенията, анализа на трафика им, да управляват разходите по приложенията и да създадат политики за скалируемост.

Разработчиците трябва да вземат предвид и технологиите, с които ще разработят бизнес приложенията. Azure предоставя множество варианти за поддръжка на различни технологии и езици, някои от които са:

1. Windows Azure SDK for Java – за разработка на Java приложения. Включва Windows Azure емулатор за Eclipse и Windows Azure клиентски библиотеки за Java.
2. Windows Azure SDK for PHP – за разработка на PHP приложения. Включва Windows Azure командни инструменти за PHP и Windows Azure клиентски библиотеки за PHP.
3. Windows Azure SDK for Node.js – за разработка на Node.js приложения. Включва Windows Azure PowerShell за Node.js и Node.js библиотеки за Windows Azure blob, table и queue хранилища за данни.

Примери на имплементация на всички клиентски библиотеки можем да намерим в GitHub.

Водене на лог, тестване и диагностика на облачни приложения

Добра практика е да вземем предвид воденето на лог и диагностиката още в началото на разработката на софтуер. Трябва да оценим дали съществуващите ни решения за лог и диагностика ще продължат да бъдат достатъчно ефективни, след като мигрираме приложението в Azure, или трябва да помислим за нови решения. Например решения, създаващи огромни лог файлове, може да имат нужда от допълнителни настройки, за да създават по-малки по големина лог файлове, които да могат да бъдат по-бързо и по-лесно анализирани, или сваляни на настолна среда за допълнителен анализ.

Следният списък предлага някои инструменти и техники за диагностика на бизнес решения в облака:

1. Windows Azure Diagnostics – инструмент, събиращ операционни и диагностични данни от Windows Azure услугите. Събира диагностични данни от редица източници като IIS, Windows Diagnostics инфраструктурни лог записи, Windows лог за събития и други, и пази събраната информация в Windows Azure Table и Blob хранилища за по-късен анализ.
2. System Center Windows Azure Management Pack – Windows Azure пакетът за наблюдение и управление ни позволява да наблюдаваме достъпността и производителността на бизнес приложенията, които са качени в облака.
3. Windows Azure Storage Analytics – предоставя лог и диагностични данни за Storage Account услугата. Можем да използваме тези данни, за да проследяваме заявки, анализираме потребителски нагласи, диагностицираме проблеми със storage account-a ни.
4. SQL Database Connection Management – управлява възникнали грешки, използвайки re-try механизъм в бизнес приложението ни.
5. Windows Azure PowerShell Cmdlets – PowerShell командите ни позволяват да търсим, конфигурираме и управляваме Windows Azure облачни услуги и услуги за управление на данни, директно използвайки PowerShell. Тези инструменти могат да бъдат полезни при разработка и тестване на Windows Azure услуги.

Също като при други типове приложения, и облачните услуги имат нужда от пълно тестване преди да бъдат прехвърлени в продуктова среда. Те трябва да бъдат тествани функционално, за производителност, за скалируемост и т.н.

Облачно базирани възможности за мрежови достъп

Azure ни предоставя множество мрежови възможности за интегриране на съществуващи приложения с облака и управление на мрежовия трафик. Основните мрежови компоненти в Azure са:

1. Windows Azure Service Bus – добра практика е да се използва за комуникации тип „услуга-към-услуга”, както и за комуникация на настолни сървъри към облака. Позволява защитено прехвърляне на съобщения през приложния слой. Услугата ни предоставя облачно-базирана инфраструктура за комуникация, поддържаща защитени услуги за комуникация в публични мрежи използвайки namespace-и подобни на https://hostname.servicebus.windows.net, а също така поддържа и различни програмни модели като .NET API, REST API и WCF.
2. Windows Azure Connect – добра практика е да се използва за сигурна връзка между настолни сървъри и облака. Това позволява достъпа на съществуващи приложения до облака, използвайки IP-базирана мрежова връзка със съществуващи настолни услуги и инфраструктура. Също така опростява директната връзка с облачно-базирани виртуални машини, позволявайки отдалечена администрация и анализ за грешки, използвайки същите инструменти, които използваме за настолни среди и приложения.
3. Windows Azure Traffic Manager – позволява ни да балансираме входящия трафик между множество Azure услуги, независимо дали те работят в един център за данни или няколко разпръснати по света центрове за данни. По този начин можем да гарантираме висока производителност, достъпност и надеждност на нашите бизнес приложения.
4. Windows Azure Virtual Network – предоставя мрежова връзка тип „точка до точка” между настолни сървъри и облака.
5. Windows Azure SQL Data Sync – услугата има две основни функции. Позволява ни да синхронизираме данни между настолни SQL Server бази данни и бази данни в Azure SQL Database инстанция, позволявайки на настолните и облачните бизнес приложения да използват едни и същи данни. Също така можем да синхронизираме между две и повече SQL Database инстанции. Допълнително, базите данни може да бъдат в един и същ център за данни, различни центрове за данни, или различни региони. SQL Data Sync услугата често се използва заедно с Windows Azure Traffic Manager.

Добри практики при мигриране на бази данни

Дори в случаите когато настолната база данни използва единствено обекти, които са поддържани от Azure SQL Database услугата, може да се наложи да направим промени, за да подсигурим правилно мигриране на бизнес приложенията използващи базата данни.

Техническите промени, които са необходими, включват следните стъпки:

1. Премахване на взаимовръзките на базата данни от функциите на SQL Server, като например репликация, които не се поддържат от Azure SQL Database услугата.
2. Премахване на взаимовръзките на базата данни с обектни типове или Transact-SQL синтакс, като дистрибутирани заявки, които не се поддържат от Azure SQL Database услугата.
3. Ако планирате да използвате базата данни само използвайки Azure SQL Database, можете да изберете поддръжка на функционалности, специфични за Azure SQL Database услугата, но ако планирате да пазите копия на базата и на настолни сървъри, използвайте функционалности и обекти поддържани и от двете среди.
4. Направете нужните промени върху приложението, което използва базата. Също така променете кода на приложението, който зависи от функционалностите, които вече не се поддържат от новата база данни.
5. Изберете процеса на миграция, постройте пакетите необходими за този процес и изпълнете процеса.

Определянето на всички функционалности на съществуващата база данни, които не се поддържат от Azure SQL Database може да се извърши без достъп до продуктовата среда, а проверявайки съществуващата документация за функционалности, поддържани от Azure SQL Database услугата, и сравнявайки тези функционалности с документацията на съществуващата база данни. Някои от тези функционалности могат да бъдат определени, използвайки инструмента SQL Azure Migration Wizard.

Много настолни бази данни зависят от услуги извън базата. Например участват в процес по репликация, SQL Server Integration Services процес, или процес по поддръжка управляван от SQL Server Agent. Миграционният процес трябва да оцени разходите по разработка необходими, тези зависимости да бъдат променени.

Разработката по базата може да бъде извършена с всякакви инструменти за разработка върху SQL Server бази данни. Предимството да използваме инструменти като SQL Server Data Tools е това, че можем да настроим build target-а да бъде SQL Azure, при което SQL Server Data Tools ще ни посочва синтакс, който не се поддържа от SQL Azure, още докато пишем кода.

Управление на мрежовото забавяне при Azure SQL Database

Освен проблеми с мрежовата връзка, мрежовото забавяне също е една от най-често срещаните проблеми с производителността.

Докато ефектът на мрежовото забавяне на интернет връзката върху производителността е известно, повечето архитекти подценяват ефекта на мрежовото забавяне между бизнес приложението и Azure SQL базата данни. Дори когато приложението и базата данни са качени на един и същи център за данни, мрежовото забавяне е по-високо от това на традиционните настолни среди. Ефектът е дори по-силен, когато става дума за приложения, които изпращат много и чести заявки към базата данни.

Освен мрежово забавяне между приложенията и Azure SQL Database услугата, има и повишено мрежово забавяне в комуникацията между различни дистрибутирани компоненти в бизнес решението. Този тип забавяне се отразява както на комуникацията на потребителя с приложението, така и на комуникацията на приложението с Azure SQL базата данни.

Response_Time = 2 x (Latency1 + Latency2) + App_Processing_Time + Query_Execution_Time

Във формулата по-горе участват следните параметри:

• Response_Time – време за отговор на потребителска заявка.
• Latency1 – мрежовото забавяне между крайния потребител и центъра за данни, на който се намира бизнес приложението (този тип мрежово забавяне се среща и при настолните сървъри).
• Latency2 – мрежовото забавяне между бизнес приложението и Azure SQL базата данни.
• App_Processing_Time – времето за обработване на заявката и върнатите данни от приложението.
• Query_Execution_Time – времето за изпълнение на заявката в базата данни.

Можем да използваме следните добри практики, за да намалим мрежовото забавяне между крайния потребител и базата:

1. Да минимизираме Latency1 – като изберем по-близко намиращ се до нас център за данни. Също така трябва да вземем предвид, че достъпът до облачна база от настолно бизнес приложение също е времеемка операция и е хубаво да я избягваме. В случаите, в които трябва да достъпим данни от множество географски локации, можем да използваме Content Delivery Network услугата за да дистрибутираме статични данни на много различни места. Или пък да създадем копия на базата в различни центрове за данни и да използваме SQL Data Sync услугата, за да синхронизираме данните между тях.
2. Да минимизираме Latency2 – като намалим броя заявки на приложението към базата данни, използвайки един или няколко от следните варианта:
   • Използване на съхранени процедури – когато правим последователни заявки, в които втората заявка зависи от резултата на първата, използвайки съхранена процедура, за да получим резултата от втората заявка, ние спестяваме една заявка от приложението към базата данни и подобряваме производителността.
   • Използване на локално кеширане – локалното кеширане ни позволява да преизползваме същите резултати, без да правим повторни заявки към Azure SQL базата.
   • Използване на Windows Azure кеширане – използваме Windows Azure кеширане за read-only данни, за да минимизираме мрежовия трафик към Azure SQL базата данни.
   • Събиране на SQL заявки в една обща заявка – можем да съберем множество Transact-SQL заявки в една обща заявка, за да получим множество резултати, или за да изпълним множество операции върху базата с една заявка. Изключително полезно е при извършване на INSERT и UPDATE операции.

Мигриране на данни към други облачни услуги

Таблицата по-долу ни предоставя възможност да сравним различни облачни услуги и кои точно да изберем при миграция на настолни приложения към облака. Таблицата сравнява услугите „Table Storage”, “Blob Storage”, “Local Storage” и “Azure Drive”, за да ни помогне да изберем правилното хранилище за данни.

Мигриране на данни към Table Storage

Azure Table storage предлага скалируемо нерелационно хранилище за данни в облака. Една Azure таблица представлява колекция от обекти. Един обект може да има до 255 свойства, където всяко свойство има име, тип и стойност. Всеки обект в таблицата има 3 задължителни свойства PartitionKey, RowKey и Timestamp.

Преди да решим да извършим миграция към Azure Table хранилището за данни е добре да помислим дали то е подходящо за съхраняване на данните, намиращи се в настолните ни сървъри. Добра практика е да използваме Azure Table Storage в следните случаи:

• Данните са структурирани и съхранявани в табличен формат.
• Данните са не-релационни.
• Данните не се нуждаят от сървърна обработка. Трябва да се уверим, че данните ни не се нуждаят от сървърна обработка като обработка на join-ове, съхранени процедури и тригъри. Table storage не поддържа сървърна обработка, но пък поддържа базови операции като Insert, Update, Select и Delete.
• Данните могат да се съхраняват, използвайки типове данни, поддържани от Table Storage, като String, GUID, Byte Array, DateTime, Int32, Int64, Double, and Boolean.

След като преработим приложението да използва Azure Table хранилището за данни, трябва да мигрираме съществуващите данни от файловата система или SQL Server базата данни към Table Storage. За да направим това, можем да напишем собствен код, използвайки HTTP(S) REST API или .NET клиентската библиотека за Table Storage, или да използваме някой от следните инструменти:

• Azure File Upload Utility – този инструмент позволява на потребителите да качат данни от файлове в Azure Table Storage.
• Azure Database Upload Utility – този инструмент позволява на потребителите да качат данни от SQL Server базата в Azure Table Storage.
• Cloud Storage Studio, част от Red Gate Software – инструмент, позволяващ ни да управляваме различни облачни хранилища за данни, включително и Table Storage.

Мигриране на данни към Blob Storage

Azure Blob услугата позволява на приложенията да съхраняват огромни количества неструктурирани данни като видео, аудио и изображения. Blob хранилището за данни съдържа нула или повече blob контейнери, а също така един контейнер може да съдържа нула или повече blob обекти. Blob обектът представлява обект от binary формат, като файл или изображение.

Blob storage услугата предлага два типа blob обекти:

• Block Blob – представлява колекция от блокове, всеки от които е идентифициран от block ID. Всеки block може да бъде с различна големина, но не повече от 4MB. Максималната големина на block blob е 200GB и един block blob може да съдържа не повече от 50 000 блока.
• Page Blobs – колекция от 512-байтови страници, оптимизирани за случайни операции за четене и запис. Записваща операция върху page blob може да презапише една или няколко страници, но най-много до 4MB.

Добра практика е да използваме Blob Storage за съхранение на голямо количество неструктуриран текст или цифрови данни като документи, изображения, аудио и видео. Също така може да се използва за съхраняване на файлове с настройки или друг тип файлове, ключови за работата на бизнес приложенията ни.

Можем да достъпваме Azure Blob Storage, използвайки HTTP(S) REST API или клиентски библиотеки за различни програмни езици и платформи като .NET, Node.js, Java и PHP.

Мигриране на данни към Azure Drive

Azure Drive е page blob, съдържащ NTFS-форматиран виртуален харддиск (VHD). Можем да създадем VHD на нашия компютър, да го качим в blob storage или използваме REST API, за да създадем blob обект, и да качим blob обекта на Azure Drive на виртуална машина. Виртуалната машина приема файлови входно/изходни заявки и ги преобразува в операции за VHD. Ако виртуалната машина претърпи срив, друга машина може да обработи същия код и да качи VHD, което да достъпи запазените данни.

Azure приложенията ни в облака могат да използват съществуващи NTFS API-та за достъп до Azure drive. Това прави по-лесна миграцията на настолни приложения, използващи NTFS API-то (или някое стандартно .NET Framework API като FileStream) в облака, с минимални промени в кода.

Само една виртуални машина може да достъпи Azure Drive за запис, но много виртуални машини могат да го достъпват за четене. Ако искаме надеждно да съхраним данните си, да ги споделим между инстанции или да ги достъпим извън Azure, можем да използваме Azure Table хранилището за данни, Blob услугата, Queue услугата или Azure SQL Database услугата, вместо Azure Drive.

Можем да създадем VHD с всички данни, да качим VHD-то в page blob, да качим blob-а като Azure Drive на виртуална машина, която да хоства инстанция на нашето бизнес приложение. Следните инструменти могат да ни помогнат с процеса:

• VHD Upload Utility – инструмент от Windows Azure Platform Training Kit, който ни помага да качим VHD файл към page blob.
• Azure Drive Explorer ни позволява да управляваме Windows Azure Drive по-лесно.
• Cloud Storage Studio част от Red Gate Software – има функционалност да ни позволи да създаваме празни page blob обекти и да качим съществуващи virtual hard drives (VHD) от компютъра ни като page blob обекти, които да се качат на Azure Drive.

Мигриране на приложения с опашки за съобщения

Опашките за съобщения са често използвани от приложения, които комуникират едно с друго или комуникират в рамките на компонентите на дадено приложение. При изграждането на архитектурата на модерните приложения, архитектите и разработчиците могат да използват опашки за съобщения, за да изградят асинхронен комуникационен канал.

Когато мигрираме приложение от настолна среда към облачна среда, е добре да анализираме текущата архитектура и дали тя позволява да използваме Azure Queues или Azure Service Bus услугите.

Windows Azure Queues услугите са базирани на Windows Azure Storage и позволяват базов механизъм за съобщения, поддържащ комуникация тип „точка до точка”. Те предоставят достъп, използвайки REST-базирани HTTP и HTTPS. Всяка опашка за съобщения поддържа капацитет от 100 TB, а всяко съобщение може да е с големина до 64 KB.

Най-често срещаната употреба на Azure опашките е използването им от уеб роля, изпращаща данни към опашката, и работна роля, която получава данните и ги обработва асинхронно.

Azure платформата поддържа и опашко-базирани Azure Service Bus услуги. Azure Service Bus също така предлага защитено предаване на съобщенията и поддръжка на дистрибутирани приложения в облака или в хибридни среди. Azure Service Bus поддържа комуникация тип „точка до точка”, използвайки Service Bus опашки, и publish-subscribe модел за комуникация. Този модел позволява много услуги-абонати да се абонират към една услуга-изпращач и да чакат да получат съобщения.

Добри практики при използването на Azure Service Bus са:

• Избиране на правилния протокол за съобщения – Azure Service Bus може да използва HTTP(S), Service Bus Messaging Protocol (SBMP) и Message Queuing Protocol (AMQP). От тези протоколи най-ефективни са AMQP и SBMP. Те осъществяват по-дългосрочни конекции от HTTP(S) и използват prefetching техники за по-бърз достъп до хранилища за временни данни.
• Паралелно изпълнение – когато можем е добре да изпълняваме операции като изпращане, получаване и изтриване асинхронно.
• Prefetching – използвайки Azure Service Bus клиентите могат да извършват prefetch операции и да зареждат допълнителни съобщения докато извършват тези операции. Тези съобщения се съхраняват в локален кеш и не се споделят между клиенти. Веднъж щом клиент извърши prefetch операция върху съобщение, други клиенти не могат да достъпват съобщението, тъй като съобщението е заключено.

Автор: Евгени Дюлгеров

---

Azure платформата е едно от най-популярните решения за облачни услуги. Ако искаш да направиш първите си стъпки в нея и да придобиеш важни практически умения за работа в облака, не пропускай практическия курс Azure Essentials – февруари 2023. Очакваме те!