С 15.06.2022 г. IE 11 не поддерживается
IE11 станет недоступным с 14.02.2023. Сайты, созданные для IE, можно перезапустить в режиме IE в Microsoft Edge.
Windows Storage Server 2012 is an advanced storage and file serving solution for any size organization that offers new levels of performance and reliability on a proven and reliable server platform.
Важно! Если выбрать язык ниже, содержимое страницы динамически отобразится на выбранном языке.
-
Date Published:
26.07.2019
File Name:
9200.16384.WIN8_RTM.120725-1247_X64FRE_SERVERSTORAGE_EVAL_RU-RU-HRM_SSTO_X64FREE_RU-RU_DV5.ISO
Windows Storage Server 2012 is built on the Windows Server 2012 operating system to provide a platform for Network Attached Storage (NAS) appliances. Windows Storage Server 2012 NAS appliances can help reduce the storage costs associated with building modern datacenters and private clouds. Windows Storage Server 2012 delivers excellent economics for a shared storage solution by leveraging industry standard hardware matched with robust storage capabilities. It delivers continuous availability that is designed to protect from a range of failures and prevent downtime in a scalable and reliable manner.
-
Поддерживаемые операционные системы
Windows Storage Server 2012
Minimum system requirements for Windows Server 2012
Architecture
x64 (64-bit)Processor
1.4 GHzMemory (RAM)
512 MBHDD free space
32 GB (more if there is 16 GB of RAM or more)
If you’ve got a some hardware lying around for your lab, Windows Server 2012 may be a great solution for a home storage device. You can now do both block (iSCSI) and NAS (NFS) on the same server, as well as having an OS to install some management apps on it. In my lab, I use this management server to run Veeam for my backups, PRTG network monitor for bandwidth tracking, as well as using this server for both iSCSI targets and NFS mounts.
Home Lab Setup
Installation
Installing the necessary components on the server is very simple.
Go to the Server Manager and choose the “Add roles and features” link.
Choose a role-based or feature-based installation.
Select your localhost if your installing from the same machine, or use the remote host option if installing from a group member.
Scroll down the list of roles and add:
- iSCSI Target Server
- iSCSI Target Storage Provider (VDS and VSS hardware)
- Server for NFS
Confirm your selections and click install
You’ve got the services installed now. The next steps are to setup an iSCSI target and and an NFS Mount. Obviously both of these are not necessary, but if you can setup both, why not do both.
NFS Setup
NFS is pretty easy to get setup for a VMware ESXi lab. Create a folder in the Windows file system; this is where your NFS mount point will be set. Right click on that folder and choose properties. Here you’ll see a tab called “NFS Sharing”. You can click on the “Manage NFS Sharing…” button to setup the properties.
Click the box to “Share this folder”. Please note that this does not share the folder for Server Message Block (SMB) like you may be used to doing for standard Windows File Shares. This is only the NFS Sharing setup. If you want, you can share this as a Windows share as well but I recommend keeping your NFS shares separate to avoid accidentally deleting files used by your ESXi lab.
Click the “Permissions” button to allow readwrite access to the NFS Share. Change the “Type of access” box to “Read-Write” and be sure to tick the check box to “Allow Root Access”
DONE! You can now setup your vSphere environment to access this NFS mount.
iSCSI Setup
To setup the iSCSI Targets, go to the “File and Storage Services” section of the Server Manager. Click on the Hyperlink to create an iSCSI virtual disk.
Choose the server and physical disk location that you’d like to create a virtual disk on. This virtual disk will be the iSCSI target so be sure to place it on the right sized and speed disk you’d like to use. In my lab i’ve got a pair of mounts, one on an SSD and one on a traditional spinning disk.
Name the virtual disk. This will end up being the file name.
Give the virtual disk a size. Obviously you’re restricted to the size of the physical disk that it’s on.
Now you need to create an iSCSI Target. Click the “New Target” section if it’s your first time running through this setup.
Give the target a descriptive name.
Now we need to list the initiators that will have access to this target. We don’t want to allow all machines to access this iSCSI disk, so we’ll limit it to our ESXi host initiators. Click the “Add” button.
Add the iSCSI initiators at the bottom. If you’ve run through this before, you can look at the initiators that are cached in the middle section.
When you’re done you’ll see all of the initiators that have access. Click “Next” to continue on.
If you are interested in setting up additional security, you can enable CHAP andor Reverse CHAP. My lab is super secure so I’ve left it disabled. 🙂
Confirm your selections and click “Create”.
The creation process will complete.
DONE! Now you have an iSCSI Target on the Windows 2012 Server. Add this target to your vSphere environment and you’ve now got block storage for your hosts.
A little backstory:
For the past year I’ve been backing up all my servers to two QNAP TS (Linux Based) NAS BOXES, both have 4 x 2 TB Drives (in a RAID 5 setup) giving me around 5TB of storage. I only really need 5TB however the second one was purchased as just one alone couldn’t handle (Kept Dropping the backups) the 13 backups over the 8 hour time period I had to do the backups.
Over the year I’ve formed a pretty poor opinion of these two boxes as backups have regularly failed as they would crash or need restarting. My second issue is that I also have another PC with my tape drive in it which must drag the data down from the NAS boxes to copy the data to the tape, this is another cause of pain as NTBACKUP doesn’t seem to like copying data from two different NAS’.
Improvements…
I finally got the chance to potentially remedy this issue this last month as a Dell TS 7400 Workstation/Server was freed up as part of my migration to virtual servers. So now I have the chassis (this beast has room for 6 HDDs + My Tape Drive) what will I stuff inside it?
First things first I want to move my tape drive into my new file server (not quite sure how it now becomes a file server but it does), the tape drive (HP 1760 SAS LTO 4 standalone) has a PCI-e SAS Card with two ports, one I will use for the tape drive and the other I will run 4 WD RED 3TB SATA drives from.
I installed Windows Server 2012 on the Workstation, surprisingly considering its a machine built for XP it installed without a hitch and even more surprisingly I found Server 2012 drivers for my tape drive and for the PCI-e Card, I’ve also chucked in 2 Gigabit Network cards teemed for more throughput and redundancy.
What no RAID?
While my PCI-e SAS card will double up as a RAID card if required I have opted to use a Windows Server 2012 Storage Pool instead, if you haven’t come across these yet; a storage pool allows you to take a bunch of storage (you can even use flash drives if you want) and then pool them together to one continuous bit of storage. On top of the pool you can then provision a virtual disk (not a VHD or VHDx) and specify if you want storage redundancy.
I’ve chose the mirror option which effectively give me RAID 10 (for some reason Microsoft don’t call it RAID 10) allowing me to lose up to 2 disks and still keep my system running, for those interested in performance my 4 bog standard WD RED disks are giving me 300MBs of sequential read/write speed which is more than enough for backups.
Saving Space!
While building this NAS I decided to implement the new storage feature ‘duplication’ so I could store more weeks worth of backups to hand onsite. While Microsoft warn me that turning deduplication on will have a negative performance effect on my server this doesn’t concern me in the slightest as my storage server does very little.
Deduplication works by comparing files and removing blocks of identical data that exist across multiple files and putting them into the dedupe central store, it then adds a reference to the original file to say that the block is now stored elsewhere (I will write this up in full at a later date), this reduces the amount of identical data that you are storing on a server.
For example say you do a daily full backup of a server to this NAS and the backup is usually around 100GB and say only 5% of the data changes everyday, without Deduplication turned on you will be looking at 700GB worth of backups over a 7 day period however if you turn deduplication on you would be looking at less than 200GB of space taken up by the same files. Using the same ratio I could be looking at storing around 17TB of data on my 5TB NAS (I see this as highly unlikely, and will report backup when I have some actual real world data to present.
Hopefully this post has given you some ideas on how you can use Windows Server 2012 to build a reliable and feature packed NAS!
Have you ever experienced data loss? In recent years, more and more people have realized the importance of data protection and have tried various methods to back up their data. In the following content, I will introduce two methods to back up Windows Server 2012 to a NAS.
Why Need to Backup Windows Server 2012 to NAS?
Windows Server 2012, as a server operating system, contains a wealth of critical information. Therefore, it’s essential to protect the data. The primary purpose of backup is to prevent data loss and quickly restore data in case of loss to ensure business continuity. As a network storage solution, NAS allows users to back up Windows Server 2012. If we can back up Windows Server 2012 to a NAS device, we stand to gain the following benefits:
1. **Centralized Storage**: NAS provides a centralized location for storing all backup files, making management and access convenient.
2. **Security**: NAS can offer various security measures, such as encryption, access control, and firewalls, ensuring the safety of your backed-up data.
3. **Redundancy and Fault Tolerance**: Many NAS systems support RAID (Redundant Array of Independent Disks) configurations, enhancing data redundancy and safeguarding against hardware failures.
4. **Remote Access**: Backups can be accessed and restored from anywhere through a network connection, which is particularly beneficial in distributed work environments.
5. **Automated Backup**: Most NAS devices support automatic backup schedules, allowing for regular backups without manual intervention.
6. **Cost Savings**: Compared to cloud backup, using NAS can lower long-term storage costs while avoiding extended backup times due to internet bandwidth limitations.
7. **Scalability**: As data grows, NAS devices can typically expand storage capacity easily by adding more hard drives.
8. **Disaster Recovery**: In the event of a primary server failure, the entire system or specific files can be rapidly recovered from the NAS, ensuring business continuity.
9. **Multi-User Collaboration**: Multiple users can simultaneously access backups on the NAS, facilitating teamwork and file sharing.
10. **Version Control**: Some NAS systems support version control, enabling you to revert to previous backup versions in case of errors or unintended modifications in the current data.
In conclusion, backing up Windows Server 2012 to a NAS device not only offers reliable data protection but also brings advantages of efficient, flexible, and cost-effective management.
- Better data protection
- Remote access to data
- Increase data storage capacity
- Share data with others
- Saving on storage costs
- Stream media across different computers
As you can see, it’s quite convenient to manage data after backing up Windows Server 2012 to NAS. After understanding the importance of backing up Windows Server 2012 to NAS, it’s time to learn how to get it done.
How to Back Up Windows Server 2012 to NAS?
Before we learn how to back up, we need to figure out what Windows Server 2012 is. Windows Server 2012 is an operating system of Windows. So when you back it up, you can also back up the Windows Server folder. And the Windows Server folder is a local folder on your computer.
Moreover, you can choose multiple ways to save the backup. For instance, you can back up Windows Server to a network share. NAS is the best option for Windows Server. There are two ways to back up Windows Server 2012 to NAS: with the tool Todo Backup Enterprise and Windows Server Backup. Both have their pros and cons.
Refer to the table and find the most convenient method:
| Comparison Items | Todo Backup Tool | Windows Server Backup |
|---|---|---|
| Backup Content | All backup content is retained. | Only one full backup can be retained. |
| Backup Types | Full, Differential and Incremental Backup | Full Backup Only |
| Backup Process | Simple | Complex |
Although system files can be backed up using Windows Server Backup, the process is relatively complex and has a higher chance of failure. Therefore, it is recommended to use Todo Backup, which provides an all-around backup solution to protect against data corruption.
Todo Backup is a professional data backup and recovery tool. With Todo Backup, you can:
- Set up automatic backups weekly and monthly.
- Perform incremental or differential backups to save space.
- Securely back up data with compression and encryption options.
- Backup all endpoint devices from a central device.
- Support for local, remote, and cloud data backup.
- Enable system cloning, hard drive cloning, and partition cloning.
- Backup multiple SQL databases in a single operation.
Todo Backup is an all-in-one data protection software that simplifies your data backup and recovery process, reducing risks and business costs. Let’s delve deeper into it.
Backup Windows Server 2012 to NAS with Todo Backup
Todo Backup is such a tool that can meet all your needs. It’s powerful and supports various Windows systems, including Windows Server. Here are the steps to back up Windows Server 2012:
Step1: Launch Todo Backup Enterprise and click «Create Task» to set up a new backup.
Click “Create new task” to create a backup.
Step 2. Select «Files» from the top options as your destination. Then choose the specific files you want to back up.
Click «Browse» to choose where you want to save the backup.
Choose a destination
4. Click on «Schedule: Off» to set up a backup schedule. You will see the options for «Schedule«, «Backup Cleanup«, and «Advanced Settings«. Click on «New» under the «Schedule» tab.
Then set the backup frequency as needed.
Alternatively, you can choose Smart Backup in your backup plan to monitor changes to selected files and back them up automatically.
Select «Smart Backup».
5. Click the «Backup Options» button in the bottom-left corner of the window.
Change the settings to your liking, for performance, encryption, email notifications, and other options. When you’re done, click Save to return to the main screen.
Step 6: Once you’ve set everything up, click «Start Backup» to begin the backup process.
Click Start backup.
Backup with Windows Server Backup to a NAS in Windows Server 2012
Windows Server Backup is a tool that comes with the Windows operating system for backing up entire disks, folders, or files. This tool is disabled by default, so you’ll need to install it before you can use it.
Step 1: Open Server Manager on your computer, and then choose Features.
Step 2: Click Add Features, and then locate Windows Server Backup.
Step 3: Click “Next” and then “Install” to complete the process.
After installing Windows Server Backup, let’s walk through a backup operation.
Click on “Windows Server Backup,” and then choose the “One-Time Backup Wizard” to begin backing up Windows Server 2012 to your NAS.
Step 2: Choose the relevant backup option, then click «Next».
Step 3: Choose a backup destination, then click Next. You can choose to back up the entire server or specific directories. The options are: «Full Server: Backs up all server data, applications, and system state» and «Custom: Choose custom volumes and files to back up.»
Step 4: On the Specify Target Type page, select Remote Shared Folder, and then click Next.
Step 5: On the Specify a Remote Folder page, type the location of the remote folder, and then click Next. This is a directory on a NAS.
Step 6: After you have verified the backup settings, click Back Up Now to start Windows Server Backup.
After the backup is complete, you can view the backed-up contents in the backup folder on your NAS.
Conclusions
NAS is a very efficient way of data storage and promotes more work sharing. With the Todo Backup tool, backing up Windows Server to NAS is a breeze. Moreover, the software is reliable, allowing you to perform quick recovery or system cloning. Additionally, after downloading the Todo Backup tool, you can enjoy many other features as well.
Frequently Asked Questions about Backing Up Windows Server 2012 to a NAS
1. What is Windows Server 2012 Backup?
A: Windows Server 2012 Backup is a feature in the Microsoft operating system that allows users to create and manage backups of server data to prevent data loss or system failures.
2. Why choose to back up to a NAS?
A: Network Attached Storage (NAS) offers a centralized solution for file storage and sharing. Backing up Windows Server 2012 to a NAS provides easy access, scalable storage space, and support for simultaneous backups from multiple devices.
3. What types of NAS backups are supported by Windows Server 2012?
A: Windows Server 2012 supports network shared backups, meaning you can back up your server data to the NAS as a network location.
4. How do I set up Windows Server 2012 backup to a NAS?
A:
a) Install and configure the NAS device on the server.
b) Create a network share on the NAS and ensure the server has permission to access it.
c) In Windows Server 2012, open the «Backup and Recovery» management tool.
d) Add a backup target and select the network share on the NAS as the backup location.
e) Define the backup schedule and choose which volumes or folders to back up.
f) Run the initial backup and confirm its success.
5. Are NAS backups encrypted?
A: Windows Server 2012 backup does not have built-in encryption for NAS backups, but you can set up encryption on the NAS device to secure your backup data.
6. How is the performance of NAS backups?
A: Backup performance depends on factors like network speed between the server and NAS, NAS processing capabilities, and the amount of data being backed up. Optimizing your network environment and using high-speed hardware can improve backup performance.
7. Can individual files or applications be restored?
A: Yes, Windows Server 2012 Backup supports selective recovery, allowing you to restore individual files, folders, or the entire system state.
8. How much storage space is needed for NAS backups?
A: This depends on the amount of data you want to back up. It’s recommended to have at least an equal amount of storage space as your backed-up data to avoid backup failures.
9. How do I maintain and monitor NAS backups?
A: Regularly check the NAS device’s storage capacity, backup task status, and network connectivity. Use Windows Server 2012’s backup management tools for monitoring and adjust backup policies as needed.
10. Can I recover my data if the NAS fails?
A: If the NAS fails, you may need to rely on alternative backup copies, such as tape or cloud backups. However, many NAS devices offer redundancy and failover features to ensure data availability.
We’ve learned that backing up to NAS is very beneficial for our work, and we’ve got the process of how to backup figured out. There are some common issues when it comes to backing up Windows Server 2012 to NAS, which we can refer to.
< strong > 1. How do I back up my server to a NAS?
There are two ways to back up a server to NAS. One is to use Windows Server Backup, but before using it, you need to install it in the Server Manager. A more efficient way is to use Todo Backup software. It’s a professional and user-friendly tool.
2. How does NAS backup work?
NAS backup relies on a backup agent, which allows the server to access the storage device – in this case, a NAS device. The data is then transferred to the backup server over the network.
3. Is NAS safe for backup?
There are great benefits to this for your data. But there are also risks, because you’re sending your data over the Internet, where it can be hacked.
Итак, вы только что закончили восстанавливать систему после сбоя. К счастью, на этот раз обошлось — сервисы, слава богу, поднялись. Но ваш босс недоволен — требует «сделать выводы и принять меры». Очевидно, настало время задуматься о том, как жить дальше. Возможно стоит пересмотреть существующие подходы к построению инфраструктуры и предпринять шаги к обеспечению отказоустойчивости вашей продакшн-системы.
Дисклеймер: заранее прощу прощения у специалистов по SAN и благородного хабрасообщества за некоторые вольности и упрощения, допущенные мной при подготовке материала. Он рассчитан на тех, кто пока еще не знаком с технологиями хранения данных, заложенными в Windows Server 2012 R2, а также тех, кто не имеет возможности развернуть у себя полноценную сеть хранения данных на базе FC или iSCSI.
С чего же начать? Рискну предположить, что для решения проблемы отказоустойчивости требуется две вещи:
- Хороший план.
- Деньги (смета).
Строго говоря, есть еще и третий пункт – «прямые руки», но его обсуждение выходит за рамки данной статьи.
С деньгами все понятно. Что касается плана, то нам необходимо разработать такую архитектуру, чтобы в следующий раз, когда случится сбой (а он обязательно случится!), система устояла. Тут придется сделать небольшое отступление. Дело в том, что в современной терминологии есть несколько устоявшихся понятий, которые часто путают между собой. Вот они:
Высокая доступность (High Availability, HA) — способность минимизировать как запланированные, так и незапланированные простои. То есть, мы (читай — заказчик) заранее соглашаемся с тем, что в случае сбоя, понадобится некоторое разумное время для переключения на резервное оборудование и запуск на нем «упавших» сервисов. Разрыв соединения при этом неизбежен. Типичный пример: кластер Hyper-V.
Отказоустойчивовсть (Fault Tolerance, FT) — способность сохранять работоспособность в случае отказа одного или нескольких компонентов. Это когда сбой произошел, но никто, кроме админа, его не заметил. Или, когда мы отключаем один из узлов, чтобы провести на нем плановое обслуживание (например, установку обновлений), а второй узел в это время берет на себя всю нагрузку. Соединение не рвется, приложения доступны, только немного увеличивается время отклика. Типичный пример: RAID 1-го уровня.
Катастрофоустойчивость — способность относительно быстро запустить сервис в случае глобальных катаклизмов. Это когда рухнуло все и сразу. В качестве глобальных катаклизмов, любят приводить в пример ураганы, цунами и наводнения. Однако, в реалиях нашей страны гораздо более вероятным представляется отключение электричества в ЦОД-е: локальное (экскаватор кабель задел) или веерное, а также затопление подвальных помещений. Пример: резервный ЦОД.
Почему важна терминология? Да потому, что перечисленные задачи принципиально разные. Соответственно, и подходы к их решению должны быть разными. Прежде всего, мы должны определиться, что именно хотим получить: высокую доступность, отказоустойчивость или катастрофоустойчивость.
В контексте данной статьи будем обсуждать только один из трех пунктов, а именно, отказоустойчивость. Справедливости ради, надо отметить, что реальная необходимость в ней возникает не часто. В самом деле, большинство заказчиков вполне готовы мириться с небольшими, прописанными в SLA, простоями в обмен на существенную экономию денежных средств за счет отказа от непомерно дорогих «сверхнадежных» решений. К примеру, если у пользователей на несколько минут подвиснет Excel, это не станет большой проблемой для бизнеса – скорее поводом немного размяться и выпить кофе. Однако, есть и такие сервисы, которые крайне чувствительны даже к небольшому разрыву сетевого соединения. Например, СУБД и гипервизоры. Если Hyper-V потеряет связь со своими виртуальными жесткими дисками, на которых запущены виртуальные машины, это может привести к печальным последствиям. Также и SQL — внезапная потеря сервером своих баз может надолго занять интересным делом DB-админа.
Итак, мы решили, что будем строить отказоустойчивое решение. Другими словами, необходимо убрать возможные точки отказа на всех существующих уровнях: серверном, сетевом и уровне хранения данных. Чем это достигается? Конечно, дублированием всего, чего только можно: серверов, сетевых интерфейсов, каналов передачи данных и, конечно, дисковой подсистемы. Тут перед нашими глазами встает светлый образ SAN. Действительно, что может быть лучше для обеспечения отказоустойчивости, чем старый добрый аппаратный FC SAN? Так-то оно так… Только есть у этого решения один убийственный недостаток. Цена. Стоимость подобной системы начинается с семизначных чисел. А верхний предел практически не ограничен. Поэтому, ее нельзя просто взять и купить – как минимум, придется забюджетировать.
Кроме того, закупая дорогущее железо, мы попадаем в серьезную зависимость от вендора, поскольку совместимость с его оборудованием сторонних производителей далеко не гарантируется. Ну и масштабирование таких систем может потребовать значительных временных затрат. Ведь дорогие комплектующие никто на складе не держит – их надо заказывать и ждать неделями, а то и месяцами. А босс требует «здесь и сейчас». И чтобы все работало «как часы». И чтобы с минимальными затратами!
Где же выход? Неужели светлым мечтам о SAN-е не суждено сбыться? Подождите… А что вообще такое SAN? По сути, это просто способ разделения ресурсов высокопроизводительных устройств хранения данных между серверами на блочном уровне. Когда-то давно классические файберные сети SAN были практически безальтернативной технологией там, где требовалась исключительная производительность, отказоустойчивость и масштабируемость. Скорость FC на порядок превышала типичный Ethernet с его 100 Mb/s.
Но со временем появились сетевые адаптеры 1 и 10 Gbit Ethernet, возникли программные и аппаратные технологии увеличения пропускной способности сети (NIC teaming, сжатие данных и т.д.), что несколько снизило преимущества FC и привело к взрывному росту популярности интерфейса iSCSI. Что касается отказоустойчивости и масштабируемости, то и тут случился прогресс. К примеру, появились варианты реализации SAN на базе хранилищ с интерфейсом SAS, который, вообще говоря, изначально предназначался для прямого подключения хранилища к серверу – DAS. Дело в том, что интерфейс SAS, помимо высоких скоростей (6-12 Gbit/s), обладает еще одним существенным преимуществом – очень малыми задержками (latency). Это весьма важно для высоконагруженных хостов, вроде Hyper-V.
А что у нас есть, кроме SAN? А кроме SAN есть только NAS. Если сравнивать SAN и NAS, то главным отличием первого от второго является работа на блочном уровне. Хост-система может создавать на SAN логические разделы, форматировать их и использовать как обычные локальные жесткие диски. NAS же работает на уровне файловой системы и использует протоколы передачи файлов, такие как SMB или CIFS. Поэтому NAS, конечно, дешево и просто, но о-о-очень медленно. А потому, для высоконагруженных продакшн-систем бесперспективно.
А нельзя ли как-то совместить высокую скорость и надежность SAN с простотой реализации и доступностью NAS? Что, если часть функционала SAN попробовать реализовать программно? Видимо как-то-так рассуждали инженеры одной скромной компании из Рэдмонда, когда готовили к выходу на рынок свою новую технологию. В итоге, у них действительно получилось нечто, по формальным признакам напоминающее SAN. Но при этом в несколько раз дешевле. Нам предлагают использовать весьма недорогие и доступные комплектующие для приготовления изысканного блюда под названием «Scale-Out File Server», т.е. масштабируемый файловый сервер. Слово «масштабируемый», на мой взгляд, не совсем точно отражает суть, поскольку, в первую очередь, сервер получился отказоустойчивым.
Итак, сегодня будем готовить «Суп из SAN» на основе технологий Microsoft Windows Server 2012 R2.
В качестве ингредиентов, нам понадобятся:
- серверы без дисков (только небольшие «зеркала» под систему) — 2 шт.;
- недорогая дисковая полка JBOD с двумя SAS интерфейсами – 1 шт.;
- HDD SAS – не менее 10 шт. (лучше – больше);
- SSD SAS – хотя бы 2 шт.;
- сетевые адаптеры 1-10 GBit (лучше – с поддержкой RDMA) – 2-4 шт.;
В качестве приправы, будем использовать рекомендованный набор специй: Storage Spaces, Tiering, SMB Direct, SMB Multichannel, CSV. Время приготовления: 1-1,5 часа при наличии опыта или 1-2 дня без такового.
Немного теории
В Windows Server 2012 и Windows 8 появилась интересная технология под названием «Дисковые пространства» (Storage Spaces). Предназначена она для абстрагирования от физического уровня дисковой подсистемы. По сути — это драйвер операционной системы, расположенный после менеджера разделов и перед менеджером томов, который позволяет виртуализировать блочное хранилище, скрывая его от операционной системы. Достигается это группировкой физических дисков в пулы и созданием на основе пулов виртуальных дисков (LUN-ов в терминологии SAN). Таким образом, все приложения будут иметь дело именно с виртуальными дисками, даже не подозревая, из чего они состоят. Но постойте… Опять виртуальные диски? Ведь эта технология под именем «динамических дисков» была реализована Microsoft (точнее, лицензирована у Veritas) аж в 2000 г. — в составе Windows 2000! Опять нам пытаются всучить залежалый товар?
Все не так просто… В отличие от динамических дисков, дисковые пространства — технология гораздо более умная, в чем мы убедимся позже. А пока уточним термины:
Пулы носителей (Storage Pools) — коллекция физических дисков, которая позволяет объединять диски, гибко увеличивать емкость и делегировать администрирование.
Дисковые пространства (Storage Spaces) — виртуальные диски, созданные из свободного пространства в пуле носителей. К атрибутам дисковых пространств относятся уровень устойчивости, уровни хранилища, фиксированная подготовка и точный административный контроль.
Кластеризованные дисковые пространства (Clustered Storage Spaces) – те же дисковые пространства, размещенные на общем хранилище — то, что нам надо!
Как создать виртуальный диск? В нашем случае, для начала, нужно объединить в пул физические SAS диски — HDD и SSD. Вообще говоря, объединять в пулы можно диски с разными интерфейсами: SATA, SCSI и даже USB. Но для развертывания отказоустойчивого кластера (Scale-Out File Server) подходят только диски с интерфейсом SAS. Объединение дисков в пул не представляет каких-либо сложностей и делается с помощью мастера буквально в два клика. Разумеется, на объединяемых дисках не должно быть никаких разделов, либо их придется удалить. Объединив диски в пулы, мы их сгруппируем. Но еще надо объяснить операционной системе, что с ними делать дальше. Теперь можно создать из дискового пула виртуальный жесткий диск (LUN). Технология Storage Spaces позволяет создавать 3 варианта виртуальных жестких дисков, подобных RAID-уровням:
- Simple (аналог RAID0) – рекомендуется только для тестов;
- Mirroring (аналог RAID1) – рекомендуется для рабочих нагрузок;
- Parity (аналог RAID5) – рекомендуется для формирования разделов с архивами данных.
Как и в аппаратных RAID, можно оставить один или два диска в горячем резерве (Hot Spare). Перечисленные возможности представлены в графическом интерфейсе по умолчанию. Однако, если этого мало, с помощью командлетов PowerShell можно получить и более хитрые комбинации, соответствующие, к примеру, RAID уровня 10.
Позвольте, скажет читатель, если это программный RAID, он ведь должен работать медленнее аппаратного! И будет совершенно прав. Да, медленнее. Но насколько? Тут все не так однозначно. Во-первых, как показывает практика, скорость дисков легко компенсируется их количеством. Поэтому, разница в производительности будет тем менее заметна, чем больше дисков мы объединим в пул. Для промышленного применения рекомендуется использовать от 12 дисков. Во-вторых, в Windows Server 2012 R2 появилась одна замечательная фича: объединение в один пул дисков SSD и HDD с формированием т.н. «гибридного пула» (Tiered Storage). В этом случае система сама будет отслеживать и перемещать на быстрые SSD диски наиболее часто используемые данные (помните я говорил, что система умная!). Причем, перемещение «горячих» данных на SSD происходит поблочно, а не на уровне файлов. Более того, с помощью командлетов PowerShell можно явно указать, какие файлы необходимо разместить на SSD, а какие — на HDD. И в-третьих, Storage Spaces поддерживают т.н. «кэш обратной записи» (WriteBack Cache). При кратковременных всплесках операций записи система перехватывает данные и размещает их в специальной области на SSD. Таким образом сглаживается падение производительности при внезапных пиковых нагрузках. Все вместе — большое кол-во дисков, гибридный пул и кэш обратной записи – способно существенно поднять быстродействие системы, сведя к минимуму негативный эффект от программного RAID. Что касается экономии свободного места на дисках, то в Storage Spaces поддерживается такая привычная для SAN технология, как Thin Provisioning – для более экономного распределения дисковых ресурсов. Справедливости ради, заметим, что пока она несовместима с гибридным пулом – придется выбрать что-нибудь одно.
Итак, средствами Storage Spaces мы можем обеспечить отказоустойчивость на уровне СХД. Теперь поднимемся на уровень выше. Серверы необходимо объединить в кластер. Эта возможность появилась у Microsoft уже достаточно давно. Однако, ранее такой кластер можно было назвать лишь высокодоступным (вспоминаем терминологию). И только с выходом Windows Server 2012 появилась возможность сделать его по-настоящему отказоустойчивым. Называется эта фича «Scale-Out File Server». Тут будет уместно напомнить, что файловые кластеры могут работать в одном из двух режимов:
- «Active — Passive»; отработка отказа с прерыванием сервиса – failover.
- «Active — Active»; прозрачная отработка отказа – transparent failover.
В первом случае только один из узлов активный – именно с ним происходит обмен данными, а второй находится в ожидании. В случае отказа первого узла, второй принимает на себя всю нагрузку. Однако, при этом происходит неизбежный разрыв соединения и прерывание в работе сервиса. Именно по такому принципу работает файловый кластер в Windows Server 2008 R2. Во втором случае оба узла активны и способны одновременно принимать данные от клиентов. В случае отказа одного из узлов, потери SMB-сессии не происходит, соответственно, работа приложений не прерывается. Эта технология появилась только в версии Windows Server 2012.
Но чтобы такая одновременная работа с хранилищем стала возможной, потребовалась очередная технология под названием Cluster Shared Volume (CSV). Если не вдаваться в подробности, это логический том, специальным образом подготовленный для одновременной работы с несколькими узлами в составе кластера.
А что на сетевом уровне? Здесь у Microsoft припасено сразу несколько приятных сюрпризов. Первый – это SMB Direct поверх технологии RDMA. Если говорить упрощенно, это технология прямого доступа к памяти через сетевой интерфейс, без накладных расходов на использование центрального процессора. При включении данной фичи сетевые адаптеры фактически начинают работать на скорости интерфейса, обеспечивая высокую пропускную способность и чрезвычайно быстрый отклик на сетевые запросы, что дает огромный выигрыш в производительности для таких рабочих нагрузок, как Hyper-V и SQL Server. Скажем так, работа с удаленным файловым сервером становится похожа на работу с локальным хранилищем. И хотя сетевые адаптеры с поддержкой RDMA пока еще достаточно дороги, их стоимость непрерывно снижается (на момент написания данной статьи составляет около 20 т.р.).
Второй сюрприз называется SMB Multichannel. Если на потребителе нагрузки (например, SQL Server) и на принимающей стороне (файловый кластер) установлено по два сетевых адаптера, то между клиентом и сервером создается многоканальное SMB-подключение. Это означает, что если, к примеру, по сети копируется файл и в процессе копирования что-то происходит с одним из сетевых адаптеров, это не приводит к прерыванию процесса – файл продолжает копироваться, как ни в чем не бывало. Чтобы убедиться в наличии SMB Multichannel, запустите командлет PowerShell: Get-SmbMultichannelConnection. Вы увидите, что-то вроде этого:
Как видно, соединение установлено при помощи сразу двух сетевых интерфейсов.
Наконец, в протоколе SMB 3.0 проведена оптимизация работы балансировки нагрузки между узлами. Как раз для конфигурации Scale-Out File Server.
Ну а теперь, когда мы кратко пробежались по технологиям, самое время перейти к практике. Для упрощения задачи будем строить двухузловой кластер, хотя ничто не мешает поднять отказоустойчивый файловый кластер, имеющий до 8 узлов. Опишем порядок действий с самого начала и приступим к его выполнению.
Подготовительные работы
Итак, берем дисковую полку в режиме JBOD. Набиваем ее дисками, хотя бы два из которых должны быть SSD. У корзины должно быть два SAS-экспандера, по два разъема на каждом. Через них подключаем корзину к двум серверам, желательно одинаковым. Для этой цели вполне подойдут простые одноюнитовые серверы. На серверах в качестве контроллеров устанавливаем обычные SAS HBA.
Далее по пунктам:
- Устанавливаем на каждый сервер ОС Windows Server 2012 R2.
- Настраиваем сетевые подключения, устанавливаем обновления, вводим серверы в домен.
- Добавляем роль Файловый сервер на каждом сервере.
- На одном из серверов открываем консоль Диспетчер отказоустойчивости кластеров.
- С помощью мастера создаем стандартный кластер с отработкой отказа (Failover Cluster).
- Создаем новый пул: Хранилище -> Пулы -> Создать новый пул.
- Добавляем в пул SSD и HDD диски, при необходимости указываем параметры доступа.
- Создаем виртуальный диск: Пул –> правый клик –> Новый виртуальный диск.
- С помощью мастера задаем тип дисковой подсистемы (Mirror).
- C помощью мастера создаем том на диске, присваиваем букву, форматируем в NTFS.
- Создаем общий кластерный том (CSV): Выбираем нужный диск -> Добавить в общие тома кластера.
- Задаем роль: Роли -> Настроить роль -> Файловый сервер -> Масштабируемый файловый сервер.
- Чтобы не ждать, сбрасываем кэш распознавателя DNS (ipconfig /flushdns).
- Выбираем роль -> Добавить общий файловый ресурс -> Общий ресурс SMB –> Профиль приложений.
- Указываем расположение общего ресурса, даем ему название.
Все. Конечным итогом наших усилий стало создание файловой шары, расположенной по стандартному UNC-пути, типа: \\ScaleOutFS\Share. Теперь можем размещать на ней критические файловые ресурсы, такие как виртуальные жесткие диски Hyper-V или базы данных SQL сервера. Таким образом, мы получили готовую сеть хранения данных. Принципиальное отличие ее от традиционных SAN состоит в том, что для подключения используется протокол SMB 3.0, а не какой-то из блочных протоколов (iSCSI/FC), что в определенном смысле является даже преимуществом. У кого-то может возникнуть желание развернуть роль Hyper-V прямо на кластерном сервере, разместив виртуальные диски на общем хранилище. Придется огорчить. К сожалению, такая конфигурация пока не поддерживается. Для ролей Hyper-V и SQL Server необходимо поднимать отдельные серверы, которые будут работать с нашей СХД по SMB-протоколу.
Осталось подвести итоги…
Отказоустойчивость
Обеспечивается на всех уровнях: хранения данных, серверов, сетевого взаимодействия.
Производительность
Будет зависеть от нескольких факторов. В типичном случае сопоставима с производительностью решений на базе iSCSI. А в случае задействования всех имеющихся возможностей, включая технологию RDMA, пропускная способность СХД окажется даже выше, чем при FC-подключении (до 56 GBit/s).
Масштабируемость
На уровне дисковой подсистемы обеспечивается простым добавлением дисков или каскадированием хранилищ JBOD. На уровне серверов – добавлением узлов в кластер. На сетевом уровне – добавлением сетевых адаптеров, объединением их в группы (NIC teaming) или заменой их на другие, с большей пропускной способностью.
Безопасность
Дисковые пулы можно контролировать с помощью списков контроля доступа (ACL), а также делегировать полномочия администраторам. Управление хранилищами может быть полностью интегрировано с ADDS.
Стоимость
Очевидно, что даже при использовании всех возможностей, заложенных в данную технологию, стоимость готового решения будет в несколько раз ниже традиционного SAN.
А как же недостатки? Разумеется, они тоже имеются. К примеру, СХД и серверы нельзя разнести на значительное расстояние, как в случае FC или iSCSI. Нельзя выстроить сложную топологию. Коммутаторы SAS – пока еще редкость. Кроме того, SAS не поддерживает аппаратную репликацию – ее придется реализовывать программными средствами. Поэтому, описанная выше концепция – не панацея, а всего лишь альтернатива традиционным СХД. Если у вас уже есть развернутый аппаратный SAN, это ни коим образом не повод от него отказываться. Железо должно отрабатывать вложенные в него деньги. Но если вы пока еще только задумываетесь об архитектуре будущей системы хранения данных, имеет смысл рассмотреть и данный вариант, как вполне обоснованный с инженерной и экономической точек зрения. Ну и напоследок хотелось бы отметить, что «суп из SAN» можно сварить не только на технологиях Microsoft. Если у вас имеется хранилище с интерфейсом iSCSI, можете воспользоваться такими продуктами, как StarWind iSCSI SAN, VMware Virtual SAN, Openfiler, FreeNAS, Open-E DSS V6 и т.п.
Приятного аппетита!
При подготовке статьи были использованы материалы портала Microsoft Virtual Academy.
Арсен Азгальдов, dpandme@gmail.com