вторник, 23 октября 2012 г.

Основные понятия резервного копирования (часть 1)

Любой человек, будь то простой пользователь домашнего ПК или системный администратор крупной корпорации, заинтересован в сохранности данных. Если это простой пользователь, то ему важно, чтобы накопленные им за годы личные фотографии или фонотека не потерялись, когда ПК неожиданно выйдет из строя. Системный администратор на предприятии вообще может отвечать головой за утрату критических данных. Рано или поздно оба персонажа задумываются о способе сохранения столь милых сердцу фотографий либо рабочих документов в каком-нибудь надёжном месте.

Резервное копирование (backup) - это процесс создания копии данных, предназначенный  для возможности их восстановления в случае их утери или повреждения. В качестве таких данных обычно выступают файлы на файловых серверах, пользовательских рабочих станциях или домашних ПК, базы данных, почтовые системы, виртуальные машины и прочее.

Как и любой другой процесс, резервное копирование требует тщательного планирования. Например, простой пользователь домашнего ПК (назовём его Эдик) может спланировать простую схему резервирования своей коллекции музыки, фотографий и кое-каких документов, сохраняя копии на другом диске, подключенном к его ПК, или на недавно купленный домашний NAS-накопитель. Помимо этого особо ценные данные Эдик копирует на USB-диск или флэшку и относит на работу, где переносит данные на рабочую станцию. Или, будучи продвинутым пользователем, пользуется средствами современных так называемых "облачных" хранилищ, таких как Dropbox или Google Drive. Вдобавок, раз в месяц Эдик записывает копии на CD/DVD диски и отвозит их к другу на хранение.

Системный администратор на предприятии (назовём его Жора) не может позволить себе держать всё в уме как Эдик. У него должен быть чёткий и понятный план по сохранению важных данных фирмы. Жоре нужна политика резервного копирования (backup policy), которая представляет собой набор процедур и правил, описывающих что и куда копировать, как часто, как долго хранить копии, допустимое время восстановления данных из копий и так далее. Немаловажной составляющей политики резервного копирования является периодическое тестовое восстановление данных для отработки и коррекции процесса и выявления ошибок на этом этапе.

Итак, и Эдик, и Жора сохраняют копии на какие-либо носители (storage media). К основным носителям относятся:
  • Жёсткие диски - это могут быть диски, подключенные к той же системе непосредственно или с помощью сетевых технологий, таких как Fibre Channel или iSCSI; жёсткие диски присутствуют в NAS-устройствах, в системах хранения данных, в виртуальных ленточных библиотеках (VTL, Virtual Tape Library), которые также могут быть задействованы в процессе резервного копирования.
  • Оптические накопители (CD, DVD, Blu-ray) используются для долговременного хранения копий; недостатком таких носителей является их малый объём.
  • Магнитная лента - носитель с последовательным доступом, имеющий долгую и богатую историю применения для целей резервного копирования, и до сих пор считающийся лучшим носителем по соотношению объёма и цены, правда, всё более теснимый по этому показателю современными жёсткими дисками; работу с магнитными лентами осуществляет ленточный привод, либо одиночный, либо в составе ленточной библиотеки.
Методы сохранения копий объектов определяют стратегию резервного копирования. К примеру, Эдик как простой домашний пользователь строит стратегию на простой основе выборочного резервного копирования (selective backup), в которой он вручную или с помощью простенького скрипта сохраняет интересующие его файлы. В промышленных системах резервного копирования такой метод тоже имеет место быть, делая безусловные копии определённого набора объектов каждый раз. Системный администратор Жора пользуется более сложной стратегией, включающей в себя классические методы полного, инкрементального и разностного резервного копирования.

Полное резервное копирование (full backup) подразумевает создание копии заданного объекта вне зависимости от того, копировался ли он ранее. Применительно к файловым серверам это обычно означает резервирование всех файлов на файловой системе (или определённого подмножества файлов). Применительно к базам данных это означает копию всех блоков, таблиц и необходимых для обеспечения целостности базы при восстановлении журнальных файлов. При выполнении копирования файлы тем или иным образом помечаются как зарезервированные, например, при помощи очистки архивного бита в метданных файла, устанавливаемого как правило при его изменении.

Инкрементальное резервное копирование (incremental backup) сохраняет только те объекты, которые были изменены с момента предыдущего полного или инкрементального резервного копирования. Это позволяет существенно сократить время операции по сравнению с полным резервированием, однако увеличивает время восстановления, так как помимо восстановления полной копии необходимо восстановить также и все последующие инкрементальные копии.

Разностное или дифференциальное резервное копирование (differential backup) также сохраняет только изменённые объекты, но только с момента последнего полного резервирования. Таким образом, с каждым разом размер разностной копии будет увеличиваться, однако положительным моментом является более быстрое время восстановления, так как в данном случае потребуется лишь полная копия и последняя разностная копия.

Дубликатное резервное копирование (copy backup) отличается от полного только тем, что объекты не помечаются, как зарезервированные. В некоторых системах резервного копирования такой метод применяется для внепланового создания некоего "слепка" без вмешательства в плановую стратегию резервирования.

Иногда применяется резервное копирование в виде образа (image backup) - вместо файлового резервирования осуществляется поблочное копирование всего тома или раздела, обычно с помощью пердварительно созданного снимка (snapshot) файловой системы. Предназначен этот метод для сохранения критических системных разделов для возможности более быстрого восстановления в случае аварии.

Ещё один метод резервного копирования называется непрерывной защитой данных (continuous data protection) и заключается в создании резервной копии непосредственно в момент сохранения файла пользователем. Впрочем, данный метод используется редко.

В следующей статье будет продолжено знакомство с основными понятиями резервного копирования.

среда, 10 октября 2012 г.

О системах счисления и единицах измерения

Пожалуй, самой распространённой системой счисления является десятичная. Считается, что основание 10 происходит от количества пальцев на руках человека. Состоит из так называемых арабских цифр: 0, 1, 2, 3, 4, 5, 6, 7, 8, 9 и является позиционной, то есть вес цифры в числе зависит от её местоположения. Например, в числе 512 "пятёрка" находится в старшем разряде и означает "пять сотен", "единица" указывает на "один десяток", ну а "двойка" в младшем разряде и есть "двойка". Если из этих же цифр сложить иное число, скажем, 125, то и значение его будет другим. Впрочем, целью статьи не является строгое математическое описание систем счисления.

В сфере информационных технологий, однако, широкое распространение получили три других системы счисления: двоичная, восьмеричная и шестнадцатеричная. Все они так же являются позиционными.

Двоичная система счисления или система счисления с основанием 2 состоит всего из двух цифр: 0 и 1. "Двойка" в такой системе записывается как 10, "тройка" - как 11 и так далее. Каждый разряд в записи имеет вес соответствующей степени двойки:

20 = 1
21 = 2
22 = 4
23 = 8
24 = 16 и т.д.

что позволяет преобразовывать двоичную нотацию в более привычную десятичную путём сложения результатов умножения цифры разряда с соответствующим множителем:

110112 = 1x24 + 1x23 + 0x22 + 1x21 + 1x20 = 16+8+0+2+1 = 2710

Обратное преобразование осуществляется постепенным делением заданного десятичного числа на 2 с записью остатков от деления в обратной последовательности:

13 / 2 = 6, остаток 1
6 / 2 = 3, остаток 0
3 / 2 = 1, остаток 1
1 / 2 = 0, остаток 1
итого 1310 = 11012.

Восьмеричная система счисления имеет основанием число 8, в которой цифры обозначаются от 0 до 7. Правила преобразования в и из десятичной системы аналогичны описанным выше для двоичной системы с поправкой на основание. Перевод в и из двоичной системы - более лёгкий процесс, так как в один восьмеричный разряд укладывается как раз три двоичных, что позволяет составить простейшую справочную таблицу для перевода. Ранее восьмеричная система счисления широко применялась в программировании, однако позже была практически вытеснена шестнадцатеричной, оставив упоминания о себе лишь в редких случаях, например, в обозначении прав доступа в системах UNIX.

Шестнадцатеричная система счисления с основанием 16 является, пожалуй, самой сложной из перечисленных с точки зрения восприятия человеком и преобразования в и из привычной десятичной системы. Помимо цифр от 0 до 9 для обозначения цифр от 10 до 15 используются латинские буквы A, B, C, D, E, F. Для перевода из шестнадцатеричной системы в десятичную и наоборот применяется аналогичный алгоритм, как и описанный выше. С двоичной системой опять всё проще, так как один шестнадцатеричный разряд составляет четыре двоичных. Область применения данной системы счисления - программирование и документация, средний пользователь сталкивается с ней разве что в виде обозначения адресов IPv6.

Для удобства преобразований из одной системы счисления в другую можно воспользоваться следующей простой табличкой:

010 = 02 = 08 = 016
110 = 12 = 18 = 116
210 = 102 = 28 = 216
310 = 112 = 38 = 316
410 = 1002 = 48 = 416
510 = 1012 = 58 = 516
610 = 1102 = 68 = 616
710 = 1112 = 78 = 716
810 = 10002 = 108 = 816
910 = 10012 = 118 = 916
1010 = 10102 = 128 = A16
1110 = 10112 = 138 = B16
1210 = 11002 = 148 = C16
1310 = 11012 = 158 = D16
1410 = 11102 = 168 = E16
1510 = 11112 = 178 = F16


Исторически использование двоичной системы в цифровой технике уходит корнями в 30-е годы XX века, когда для счётных машин применялись реле и переключатели с двумя положениями, фактически "включено" и "выключено", что отлично укладывалось в двоичные разряды, где "ноль" обозначал "выключено", а "единица" - "включено". А труды Готфрида Лейбница, в XVII веке подробно описавшего двоичную арифметику, и Джорджа Буля, разработавшем в XIX веке булеву алгебру, явились тем краеугольным камнем, на котором и основывались счётные машины и, по сути, вся современная техника.

В 1948 году Клодом Шэнноном было предложено использовать для обозначения двоичного разряда слово бит (bit от binary digit). Именно бит представляет собой наименьшую единицу информации, все остальные фактически являются производными.

Ниббл, именуемый также тетрадой или полубайтом, состоит из четырёх двоичных разрядов, что даёт 16 различных значений, легко обозначаемых одной шестнадцатеричной цифрой. На практике в документации или иных источниках встречается редко.

Гораздо более известной единицей информации наряду с битом является байт (byte от binary term). В современной вычислительной технике байт содержит восемь двоичных разрядов и может принимать 256 различных значений. Стоит отметить, что исторически использовались байты и других размерностей, например, 6-битный байт в машинах PDP-10. Поэтому для восьмибитных байтов существует также более строгое и верное название октет, широко применяемое в сетевых протоколах.

Два и более байт могут составлять слово (word), размер которого зависит от платформы и как правило зависит от разрядности регистров процессора или шины данных. Порядок байтов в слове также может быть разным: от старшего к младшему (big-endian), применяемый, в частности, в сетевых протоколах, или от младшего к старшему (little-endian), наиболее распространённый в архитектуре x86.

На протяжении нескольких десятилетий для обозначения больших объёмов информации использовались приставки СИ для кратных величин: килобайт (равный 210 или 1024 байт), мегабайт (равный 220 байт или 1024 килобайт) и так далее. Однако, если строго следовать букве стандарта, то выясняется, что подобное использование приставок некорректно, так как приставка "кило-" означает 103 или 1000 байт, приставка "мега-" - 106 или 1000000 байт и тому подобное. В результате во избежание этой путаницы в конце 90-х годов XX века Международной электротехнической комиссией (МЭК) были предложены, а в конце 2000-х годов институтом IEEE установлены стандартом новые приставки, основанные на приставках СИ, в которых вторая часть названия заменена на слог "-би". Таким образом появились "кибибайты", "мебибайты", "гибибайты" и прочие "-бибайты". Отечественный ГОСТ, однако, отдаёт предпочтение "некорректным" наименованиям и основывается на степенях двойки. Следующая небольшая табличка представлена для сравнения названий:

ГОСТ 8.417-2002:
байт (Б) = 20 = 1 байт
килобайт (КБ) = 210 = 1024 байта
мегабайт (МБ) = 220 = 1048576 байт
гигабайт (ГБ) = 230 = 1073741824 байта

Приставки СИ:
байт (B, Б) = 100 = 1 байт
килобайт (KB, КБ) = 103 = 1000 байт
мегабайт (MB, МБ) = 106 = 1000000 байт
гигабайт (GB, ГБ) = 109 = 1000000000 байт

Приставки МЭК:
байт (B, Б) = 20 = 1 байт
кибибайт (KiB, КиБ) = 210 = 1024 байта
мебибайт (MiB, МиБ) = 220 = 1048576 байт
гибибайт (GiB, ГиБ) = 230 = 1073741824 байта

Несмотря на стандартизацию названий двоичные приставки не снискали популярности среди пользователей и в устной речи практически не используются, а вместо этого применяются старые добрые СИшные приставки.

Тем не менее производители жёстких дисков сумели воспользоваться неразберихой с пользой для себя, указывая на своих продуктах гигабайты и терабайты в системе СИ, в то время как большинство операционных систем до сих пор оперируют теми же гигабайтами и терабайтами в их старых значениях степеней двойки, тех, что нынче правильно называть гибибайтами и тебибайтами. Однако, пользователи-то в основном привыкли также к старым названиям. Поэтому у них зачастую возникает недоумение, почему это их только что купленный жёсткий диск объёмом 3 терабайта в операционной системе представлен как диск объёмом 2,7 терабайта, и куда нехороший производитель задевал недостающие 300 гигабайт.

четверг, 4 октября 2012 г.

IBM объявил о выходе новых продуктов

3 октября 2012 года вышел пресс-релиз, в котором представлены новые продукты IBM в области систем Power Systems, систем хранения данных и программного обеспечения. Опубликован также Announcement Summary с более подробной информацией о новинках.

Вот краткий перечень наиболее заметных продуктов:

Система хранения данных IBM System Storage DS8870 - это новая флагманская СХД в линейке IBM System Storage DS8000. Построена на базе процессоров IBM POWER7 (предыдущий флагман DS8800 имел процессоры IBM POWER6+), поддерживает от 16 ГБ до 1 ТБ памяти для кэша (DS8800 - от 6 ГБ до 384 ГБ) и максимальное дисковое пространство до 2304 ТБ данных (аналогично DS8800).

Обновлённые системы IBM Power 770, IBM Power 780 и IBM Power 795 представлены новыми моделями, использующими последние процессорные разработки IBM POWER7+, высокопроизводительные контроллеры ввода-вывода и модули памяти высокой плотности, позволяющие получить в одной системе до 4 ТБ (до 16 ТБ в системе IBM Power 795).

Обновлены, соответственно, связанные с Power Systems программные продукты, такие как операционная система IBM AIX версий 6 и 7, средства виртуализации PowerVM и средства высокой доступности PowerHA.

Объявлено также о выпуске новой модели Hardware Management Console (HMC) - программно-аппаратного комплекса для управления системами Power Systems - с типом-моделью 7042-CR7, очевидно, построенной на базе сервера System x3550 M4. Программное обеспечение теперь имеет версию V7R760.

Для ленточной библиотеки уровня предприятия IBM System Storage TS3500 выпущен накопитель IBM System Storage TS1060, являющийся первым для компании IBM приводом стандарта LTO Ultrium 6-го поколения.

Линейка продуктов IBM Tivoli Storage Manager (TSM) обновлена до версии V6.4. При этом сервер в отличие от остальных компонент будет иметь номер версии V6.3.3. Основные изменения коснулись клиентской части TSM for Virtual Environments. Обзор новой версии будет ближе к концу ноября, когда продукт станет доступен для загрузки.

С остальными новинками и обновлениями можно ознакомиться в пресс-релизе и анонсе, ссылки на которые приведены в начале статьи.

вторник, 2 октября 2012 г.

Установка HMC на неподдерживаемую платформу

Hardware Management Console или HMC - это средство управления системами IBM System p, IBM System i и IBM Power Systems. Поставляется как программно-аппаратный комплекс, имеющий определённые тип и модель оборудования:

Серверы, устанавливаемые в стойку (размером 1U):
7310-CR4, 7042-CR4 собраны на базе сервера IBM System x3550;
7042-CR5 собран на базе сервера IBM System x3550 M2;
7042-CR6 собран на базе сервера IBM System x3550 M3.

Серверы типа "Tower":
7310-C06, 7042-C06 собраны на базе сервера IBM System x3200;
7042-C07 собран на базе сервера IBM System x3200 M2;
7042-C08 собран на базе сервера IBM System x3200 M3.

Тип и модель сервера определены в базовой системе ввода-вывода (BIOS) и совместно являются тем идентификатором, которым пользуется программа установки программного обеспечения HMC для проверки соответствия поддерживаемого оборудования. Само программное обеспечение построено на базе ОС Linux (OpenSUSE) и платформы Java. Управление осуществляется через браузер либо с помощью командной строки.

Формально, как и для любого коммерческого программно-аппаратного комплекса, лицензионное соглашение ограничивает использование программной части в отрыве от того оборудования, на котором она установлена производителем. Во избежание ситуаций, когда единственный HMC выходит из строя, что влечёт за собой потерю управления подключенными к HMC серверов, IBM, понятно, рекомендует устанавливать дублирующий HMC. Однако, если всё же в целях экономии, как это часто бывает, в наличии имеется всего один HMC, и он выходит из строя, то на время ремонта, замены или закупки оборудования администратор не может полноценно управлять ввереными ему на попечение серверами.

Выходом из ситуации для такого администратора была бы возможность временно установить программную часть комплекса на имеющийся свободный сервер или даже на виртуальную машину. Сам дистрибутив ПО HMC доступен для загрузки в виде iso-образов дисков восстановления на сайте Fix Central. Вся проблема в том, что при попытке установить ПО HMC на какой-либо сервер с идентификатором типа-модели отличного от списка выше или виртуальную машину непременно появится сообщение о неподдерживаемой платформе с предложением выключить сервер и больше так не делать.

Сообщение о неподдерживаемой платформе


Как быть? Есть три варианта, из которых два предполагают замену типа-модели в микрокоде сервера, а третий - подмену идентификатора в дистрибутиве HMC.

Первый вариант: в наличии есть старенький сервер IBM. Например, xSeries 326 или что-нибудь посвежее из первого поколения System x, скажем, тот же x3550, на основе которого собраны HMC 7310-CR4 и 7042-CR4. Подобные серверы в качестве микрокода использовали BIOS. Единственной возможностью заменить тип-модель на таком сервере является перепрошивка BIOS. Для этого с сайта ibm.com из раздела поддержки или того же Fix Central необходимо скачать загрузочный образ дискеты или iso-образ, содержащий микрокод BIOS, записать полученный образ на соответствующий носитель и загрузить с него сервер. До прошивки будет задан вопрос о типе-модели сервера, где и можно задать тип-модель из списка в начале статьи.

Запрос о замене типа и модели сервера

По окончанию этой операции ПО HMC должно установиться на такой сервер без проблем.

Второй вариант: в наличии есть более новый сервер IBM с UEFI в качестве микрокода. Это серверы System x поколения M2 и выше. На них тоже есть возможность заменить тип-модель, при этом без перепрошивки микрокода, а с использованием утилиты Advanced Settings Utility (ASU) из набора инструментов IBM ToolsCenter. Если на сервере ещё установлена операционная система Windows или Linux, то изменить настройки можно, загрузив утилиту ASU под соответствующую версию ОС. Если же никакой системы на сервере нет, то утилиту потребуется интегрировать в загрузочный образ WinPE или Linux LiveCD, после чего осуществить замену типа-модели, загрузив полученный образ и запустив ASU.

"Магическая" командная строка ASU для получения необходимого результата выглядит следующим образом:

asu set SYSTEM_PROD_DATA.SysInfoProdName 7042CR6

Вместо "7042CR6" можно подставить любое другое значение из списка в начале статьи.

Третий вариант: в наличии нет серверов IBM, но есть серверы других производителей, либо хочется воспользоваться технологиями виртуализации VMware, Hyper-V или, скажем, VirtualBox. Тогда первые два варианта не подходят, и придётся немного потрудиться, исправив установочный образ HMC в соответствии с инструкциями, подробно изложенными в статьях Installing HMC in VirtualBox or VMWare и Running HMC V7 R3.3.0 in VMWare.

Итак, способы запустить ПО HMC на неподдерживаемой платформе существуют. Однако, формально это является нарушением лицензионного соглашения с лишением права на поддержку, поэтому рекомендуется рассматривать эти способы как временное решение в случаях выхода из строя основного и единственного HMC на предприятии.