Всякое #1 — Это комплексный вопрос…

by admin

Я меня есть друг, он проработал лет 5 в отделе по торгам, и понял, что это не его, это скучно и проч проч. Закрылась фирма в которой он работал и под этим соусом он решил круто поменять свою жизнь и связать ее с IT. Похвально, но есть небольшая загвоздка, он не шибко шарил в компах, винду переставить и по мелочи. И он спрашивал меня на счет всяких обучающих видео, статьях, но я, если честно, не смог посоветовать ничего адекватного. А человек хотел вгрызться в это дело с головой — значит надо было помогать. Сейчас он уже в интеграторе, и длительное время работает сисадмином.

У меня был файлик, по которому мы в свое время искали сисадминов на фирму, файлик постоянно дополнялся, обновлялся и получился некий список, по которому можно было отсеивать кандидатов. Вопросы от простых до сложных. Но вопросы-маркеры, скорее. т.е. если человек смог ответить на вопрос, всегда можно было копнуть чуть глубже, чтобы понять глубину знаний. Потом, конечно, этот файлик был не нужен и собеседования проводили без него.

Так вот, к чему я все это? Я передал ему этот документик, чтобы он по каждому пункту находил ответы, попутно, читая по темам около. Как только он находил ответы на эти вопросы, по каждому из них я дописывал вопросы по теме чуть глубже и отправлял его читать опять. Не подумайте, это не было на отлюбись, я был готов ответить на любой вопрос, но только после того, как он прочел документацию и сказал, что именно он не понял.

Есть тут ламповый телеграм-чатик по VMware, и там куча вопросов приходит в стиле:

Выглядит это вот так:

ИМХО, это не адекватное поведение человека, а уж тем более, айтишника. 90% можно нагулить на первых строчках гугла, а не вот это вот все…
Но есть, к счастью, и вопросы другого типа. Один из таких попался моему знакому в соседнем чате по бекапам и я с его разрешения утащил часть размышлений на тему, и решил написать дополненную мини статью-ответ. Не все сразу становятся архитекторами. А кто-то и не становится.

Вопрос
Добрый день. Есть два сервера на каждом из которых висят виртуалки. Образы дисков находятся на HDD/SSD в самих серверах (RAID1), а бэкапы делаются на два NAS по локальной сети.
Хочу иметь возможность вынести эти виртуальные диски за пределы сервера, ну что бы при этом производительность не упала. Так же увеличить скорость создание бэкапов виртуалок. В интернете в принципе полно информации про SAN , NAS и DAS , iSCSI и Fibre Channel …. Но я больше запутался во всем этом. Может кто своим примером поделиться и подсказать как это организовывается ?

Хороший вопрос, но т.к. спросили много всего и сразу в паре предложений, отвечаться придется чуть более развернуто. Без приколов и докапываний, просто по опыту, многие люди не могут ответить на простые вопросы — «Зачем?».

А не хуйню ли я делаю? — Мой творческий путь

Основной вопрос у человека — увеличить скорость создание бэкапов виртуалок. Сразу много вопросов:

  • Зачем? Ну, то есть, чтобы что?
  • У вас не пролезает бекап в окно резервного копирования?
  • Сколько вы готовы заплатить?
  • Насколько быстрее вы хотите делать бекапы?
  • Почему вы считаете, что они делаются долго?

Вопрос второй — Хочу иметь возможность вынести эти виртуальные диски за пределы сервера.

  • Зачем? Ну, то есть, чтобы что?
  • Что вы хотите этим добиться?
  • Сколько вы готовы заплатить?
  • Нужна отвязка от физического сервера на случай поломки?
  • Получить гибкость в управлении?

Продолжение прошлого вопроса — что бы при этом производительность не упала.

  • Сколько вы готовы заплатить?
  • Нужно чтобы только не упала? А если будет больше?
  • Вам не хватает существующей производительности?
  • Если упадет на 5-10%, заметите разницу?

1. Короткий ответ

>>Хочу иметь возможность вынести эти виртуальные диски за пределы сервера
Нет проблем, любая СХД или даже дисковая полка / DAS позволят это сделать.

>>ну что бы при этом производительность не упала.
С этим сложнее. Такие же локальные диски будут “быстрее”, за исключением разве что подключения дисковой полки напрямую к контроллеру на сервере, и экзотики типа PCI-E switch
PI7C9X2G612GP и то этот вопрос еще необходимо обговорить отдельно.
Говоря про “быстрее”, и “производительность локально” надо сделать ряд оговорок и уточнений.
Никто давным давно не читает данные “прямо с блинов / SSD”. Есть буфер на самом диске. Есть буфер на контроллере. Есть буфер в оперативке (хитрая винда такая хитрая).
В некоторых ситуациях, если мы много и разнообразно читаем / пишем на low-end (читай — дешевый, встроенный, софтовый**) RAID-контроллер, то он может и проиграть дисковой полке. При этом, если мы устроим pass-through mode для дисков, и заведем SDS, то еще вопрос, что будет быстрее.

** В том числе, например, Intel® Virtual RAID on CPU (Intel® VROC) — тоже формально soft raid

Вопрос в том, насколько и как именно быстрее, и критично ли это. Судя по уровню продаж традиционных СХД — очень, очень некритично во многих сценариях.
Судя по результатам продаж таких SDS решений как Nutanix, MS S2D, VMware VSAN — все не так однозначно.

>>Так же увеличить скорость создание бэкапов виртуалок.
Нет проблем. Один вопрос — сколько вы готовы за это заплатить? Для начала анализ, где у вас узкое место — на источнике, в сети или в точке хранения?
Судя по последующим сообщениям “я собрал LACP между коммутатором и NAS — а скорость не выросла” — проблема прежде всего в недостаточном уровне знаний.

>>Может кто своим примером поделиться и подсказать как это организовывается ?
С этого места начинается длинный рассказ, с множеством упущений и упрощений.

2. Длинный ответ “в общем”

Для начала определимся с архитектурой.

Пропустив вопрос выбора среды передачи, который все равно сведется к оптике, выбор встанет между Ethernet и Fibre Channel (Infiniband — опционально).

С Ethernet все просто (ну-ну, как сказать).
Это все тот же старый добрый 10/100/1000 или 1/10G Ethernet. Сюда же 25, 4*10=40, и 4*25=100, вместе с их QSPF28.
Или же новый, не добрый iWarp / RoCE v1- v2) и прочие Data center bridging / lossless Ethernet для FCoE и не только.

Fibre Channel с его 4/8/16/32 живет своей, совершенно особой и отдельной жизнью.
Там уже:
— свои карты,
— свои SFP модули,
— свои свичи (Brocade, Cisco MDS). С Ethernet это не совместимо никак.
(ну как “никак”. Есть FCoE, есть коммутаторы “про то и другое” — например Nexus 93180YC-FX*, есть HPE Flex fabric, Huawei CX311 / CX320 — но с их рассмотрением заметка вырастет на километр).
* The Cisco Nexus 93180YC-FX Switch (Figure 1) is a 1RU switch with latency of less than 1 microsecond that supports 3.6 Tbps of bandwidth and 1.2 bpps. The 48 downlink ports on the 93180YC-FX are capable of supporting 1-, 10-, or 25-Gbps Ethernet or as 16-, 32-Gbps Fibre Channel ports

Для простоты, на самом простом и дешевом уровне есть выбор между
1/10 Gbit Ethernet
8 Gbit FC

Оба варианта поддерживают т.н. loop (петлю) — в смысле, сервер (хост) и СХД можно подключить без коммутатора (свича) — кабелем, точка-точка. Есть исключения, конечно, как NetAPP FAS, на его физических портах используется NPIV, а сервер не знает, что с этим делать.

Ключевое отличие:
— при включении Ethernet через коммутатор он работает “из коробки” (сам коммутатор. От настройки IP и прочего IQN никто не избавит).
— при включении FC — из коробки скорее всего не работает, надо провести первоначальную настройку коммутатора (два часа на чтение гайда (руководства), 5 минут на вбивание 5 команд для Zonning в консоли. Есть отличный цикл статей от Евгения Елизарова по этой теме.
Но консоль понадобится, а значит понадобится и USB2COM шнурок и не только — впрочем, он же будет нужен и для настройки коммутатора), Хотя, сейчас, новое железо идет уже с micro-USB который эмулирует COM.

Небольшое уточнение про сети.
Когда мы говорим про сети, то надо понимать следующее:
— в случае Ethernet само по себе LACP не подразумевает увеличения скорости для одного потока при одинаковом source / destination MAC (если используется такая балансировка)
— в случае MPIO и для Ethernet и для FC надо понимать, что это и как работает, и где может быть узкое место и почему оно не будет расшито
— в случае MPIO надо отдельно обратить внимание на параметры политики по умолчанию (short first / Round Robin IOPS limit и особенно ANO). Читать тут, тут и тут
ANO = useANO = Use Active-Non-Optimized.

Файловый и блочный доступ. (Объектный пока что пропустим).
На ваш выбор, в зависимости от желания и гипервизора.
Правда, в случае FC выбор несколько ограничен, файлового доступа тут нет 🙂

Скорость работы и тип нагрузок.
Скорость работы — вещь специфическая, и зависит от типа нагрузки.
необходимо отличать: OLTP и OLAP

OLTP (Online Transaction Processing), транзакционная система — обработка транзакций в реальном времени. Способ организации БД, при котором система работает с небольшими по размерам транзакциями, но идущими большим потоком, и при этом клиенту требуется от системы минимальное время отклика.

С другой стороны линейки находится OLAP:
OLAP (On-Line Analytical Processing) — много (очень) много данных, но при этом надо обработать “все”, но при этом время исполнения (задержка исполнения) единичной операции не так критична.

Если свосем кратко: Для OLTP нужно много IOPS, для OLAP — Throughput. Про это у меня тоже есть цикл статей.

Линейную и случайную нагрузку.
Для одних задач нагрузка будет “скорее всего линейной” (видеоредактирование), для других (базы данных, например Jet Database Engine) — сильно случайная.
Например, если мы пишем какие-то данные сначала в transaction logs, потом в базу, то transaction log file будет писаться “куда-то дальше в свободное место”, но в самой базе изменяемые блоки данных могут быть (и будут) размазаны по всему файлу с данными.

Соотношение чтения-записи и Raid write penalty
(сюда же идет магия “запись полным страйпом и прочие ухищрения с размерами блоков)

После понимания этого можно в первом приближении свести показатели скорости к
— задержкам при случайном чтении/записи (latency)
— количеству операций ввода-вывода (IO) в секунду (per second) — IOPS
— скорости линейного и случайного чтения каким-то блоком в мегабайтах/сек.

Что в конце?
В конце всей цепочки, кроме прочего, стоят еще и проблемы и ограничения файловой системы.
Это, в первую очередь, проблемы выбора NTFS/ReFS для Windows. Особенно зависимости сценария/версии Windows Server.
Если кто не знает, то MS несколько раз менял публичное мнение и документы о том, что ReFS это хорошо / хорошо не всегда / хорошо только если , и сейчас снова меняет.
используйте NTFS.

Примечание от коллег: Сильно на производительности использование NTFS не скажется (ReFS чуть быстрее при использовании динамических дисков — аналог Lazy Zeroed у VMware, но подходит не для всех сценариев). Или если вам не нужно использовать блочные клоны для быстрого копирования больших файлов в рамках одного тома. Также у ReFS есть дедупликация, и те же бекапы Veeam’ом будут дедуплицированны на уровне ReFS. Про это можно почитать тут.

Скорость бекапа, про которую разговор.
Скорость бекапа зависит от многих вещей. Рассмотрим простую схему — некие данные лежат на внешнем хранилище, подключенном по FC к хосту.
Как забрать эти данные на destination / точку хранения?
Как подключена точка хранения? Как организован data flow? Кто будет забирать эти данные? Каким путем? Будут ли при этом использоваться преимущества виртуализации (change block tracking)?
Умеет ли внешнее хранилище выполнять собственные аппаратные снимки (снапшоты), или только скриншоты?
Умеет ли используемая система резервного копирования работать с этими снапшотами?
Что будет являться узким местом / бутылочным горлышком / bottleneck для данной схемы? Что с целостностью данных на момент резевного копирования?
Зачем нужно повышать скорость резервного копирования, для решения каких задач в разрезе RTO / RPO ?
Будет ли использоваться схема 3–2–1 или достаточно 2 копий данных, одна из которых в данный момент — рабочая?
Вообще, сколько стоят ваши данные и сколько стоит остановка в работе?

После ответа на эти простые вопросы можно посмотреть кто слабое звено, кто тормозит всю команду — источник (source), сеть или destination.
И надо ли это ускорять. И как.

3. Некоторые моменты, которые все равно всплывут.

Ниже всего у нас находится среда передачи, и вопросы по ней будут.
Среда передачи может быть: медный кабель, оптический кабель или радиоэфир.
Медные кабеля могут быть категории 5е / 6 / 6A, экранированные / не экранированные. Предельная скорость передачи определяется пропускаемым частотным спектром (проще говоря, пропускает ли кабель частоты порядка 100 / 250 / 500 МГц). В настоящее время на кабеле категории 6 можно использовать 10 Гбит сеть.
На кабеле категории 5e в последнее время стало можно поднять не только 1G, но и 2.5 / 5G.
Частота использования медных кабелей: постоянно. Те же DAC кабеля — медные (по определению — A Direct Attach Copper cable or a DAC cable is a twinax copper cable that connects directly the ports (or line cards) within active equipment, such as switches, routers, servers or data storage devices, in a data network.)
Коннекторы: все те же RJ-45.

Оптический кабель.
В этом месте часто возникает путаница fiber / fibre. Первое — тип кабеля. Второе — Fibre Channel Protocol (FCP).
Для простоты — кабель бывает 2 типов — multimode / single mode. Встречаются и те и другие, невооруженным глазом — не отличаемы,
так что на самом кабеле есть маркировка (MM/SM).
Мультимод кабель бывает разный — Multi-mode cables can be found in OM1, OM2, OM3 and OM4 types.
Сингл мод тоже бывает разный, OS1 / OS2.
Прочитать можно тут и тут. Какой-то дичайшей принципиальной разницы в эксплуатации между ними нет — оба типа сильно гнуть нельзя, адаптеры (SFP) MM используем с кабелем MM и наоборот, кабель SM — адаптеры SM.

Коннекторы.
Их полно разных, смотреть тут. Чаще всего можно увидеть коннектор LC.

Важно знать! В обычном оптическом кабеле (патчкорде) две оптические жилы. В одну жилу светит сторона А, в другую — сторона В. С другой стороны — стоят приемники:
A(передатчик) -> B(приемник)
B(передатчик) -> A(приемник)


Поэтому, смотрите внимательно, что во что вы включаете, на патчкорде есть два колечка с буквами A/B и они там не просто так.
Патчкорд LC разборный (но разбирается плохо).
Существуют и используются “одноглазые” совмещенные приемо-передатчики, работающие по одной жиле на разных длинах волн, наиболее часто встречаются в конверторах (Singlemode vs. Multimode).

Радиоэфир.
На 2020 год я не видел СХД, подключенных по Wi-Fi. Не то чтобы это невозможно — пожалуйста, дома это сделать вполне реально.
В помещении заменить даже 4*10G — вайфаем будет немного затруднительно (но, повторюсь, для дома — можно).

Direct-Attached Storage (DAS) кабель.
Надо понимать, что под маркой DAS может идти и SAS, и eSATA, и USB, и даже IEEE-1394 FireWire и прочий Thunderbolt.
Для, как подсказали коллеги — нишевого, но решения — Внешний SSD PROMISE Pegasus R6 12TB — Promise P3R6HD24US Pegasus3 R6 24TB (6x4TB) Thunderbolt 3 RAID Storage

4. Рекомендованный список литературы.

  • EMC. От хранения данных к управлению информацией (EMC Information Storage and Management: Storing, Managing, and Protecting Digital Information in Classic, Virtualized, and Cloud Environments).
  • EMC Information Storage and Management — Student Guide
  • sysadmins №2. СХД, SAN, VSAN, CEPH и прочие SDS.
  • HK902S Managing HPE 3PAR StoreServ I: Management and Local Replication.
  • HK904S Managing HPE 3PAR StoreServ II: Optimization and Remote Replication.
  • «Главная книга» Nutanix — http://nutanix.ru/ — очень полезная обзорная (и потом уже не только обзорная) книга «как это работает». На русском.
  • Доклад Highload 2016. Что уже умеют промышленные СХД.
  • Презентации семинара “Brocade SAN для начинающих — просто о сложном”
  • Григорий Никонов. Основы теории Brocade SAN. часть 1
  • Григорий Никонов. Основы теории Brocade SAN. часть 2
  • Backup For Dummies — Acronis eBook
    Оставлю ссылочкой, на всякий. https://habr.com/ru/post/346352/

5. Для тех кто дочитал
Есть еще DRP — disaster recovery plan (DRP) и Bit rotting / silent data corruption…
В том числе, если мы говорим про бекап
— Можно ли его вообще восстановить ?
— Что для этого нужно сделать, куда бежать, что нажимать?
— Куда будет идти восстановление при различных сценариях сбоя?
— Как и за счет чего будет обеспечена целостность восстановленных данных?

6. The end или вместо окончания
Для предложений “как сделать хорошо” сейчас не хватает информации “как сделано сейчас”.
Какие (7200/10к/ssd) и сколько дисков установлено на серверах источниках?
Как сервера подключены к NAS, сколько путей и какая скорость подключения?
Что там в NAS — какой он, с каким софтом, какие диски установлены, сколько дисков, в какой массив собраны?
Проведен ли сбор хоть каких-то данных — обьемы бекапов, скорость бекапа “сейчас”, узкие места?

Скоре всего проблемы везде:
— сеть 1G (решение — поставить коммутатор 10G, тот же Netgear, разобраться как работает LACP).
— исходные диски 7200 (не решаемо, кроме как заменой дисков или покупкой СХД/DAS).
— диски в точке хранения (NAS) медленные и их мало (в этом случае возникает вопрос к тому, можно ли поставить туда 1–2 SSD и использовать их под кеш или включить тиринг?

А вот про кеш и тиринг у нас в следующей статье (она на подходе)!

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *