Старые журналы: ReadMe N2/1993 год
Статья о трудностях системного администрирования 16 лет назад. Вероятно понравится Жоре.
Журналы: ReadMe N2/1993 год, Обложка
Статья:
Из воспоминаний старого администратора
Или о том, как избежать забот
Мартовское утро. Начало рабочего дня. За окном холодно, безлюдно и сонно. Ты садишься за письменный стол, завариваешь кофе и знаешь, что этих чашек кофе будет еще много... Звонит телефон. Голос коллеги сообщает, что у нее что-то не получается с выходом в сеть. Слава богу, что хоть что-то происходит, небольшая прогулка к серверам хоть немного тебя освежит. При следующем телефонном звонке ты уже не поднимаешь трубку, жаль времени, ведь как всегда-«проблемы с выходом в сеть».
Ты бесстрашно подходишь к серверам. Ты знаешь, что ты-хороший специалист, в твоем распоряжении кроме обычных средств - NetWare 3.11, источники бесперебойного питания, дуплексы, система архивирования - в общем, спокойствие полное.
Опыт тебя научил, что катастрофы происходят только с другими. Смотришь на дисплей первого сервера и не веришь своим глазам: «SYSTEM HALTED»! В кровь поступает доза адреналина! Сонливость исчезает без следа. Нужно действовать! Система просит разрешения для записи диагноза на дискету - пусть записывает. Холодная дрожь в плечах, сервер не реагирует. Зависание сервера - это не пустяк, но в то же время и не катаклизм. Последнее сообщение на экране успокаивает, что повторный запуск системы произойдет после повторного включения питания. С биением сердца ты включаешь сервер и ждешь.
Ожидая, ты думаешь об общих теориях сохранности данных, о том, кок хорошо, что у тебя есть второй сервер, а особенно-стриммер, о котором ты всегда думал как об устройстве сохранения скорее для самоуспокоения, чем как о реальном, полезном оборудовании. Ты дожидаешься и знаешь, «что тебе хорошо, но не безнадежно». Сервер не работает - сигнализация об ошибке от первого DCB.
Ничего не поделаешь, это железо, работа для техников. Телефон не умолкает, это нормально, все нетерпеливы. Время идет. У тебя есть второй сервер и страховые ленты с первого, но переконфигурация сети в односерверную занимает много времени, а фирма без информации жить не может. Ты думаешь о дуплексном режиме - ведь делать-то что-то надо! Достаточно локализовать ошибку, потом сервер заработает на одном канале. И почему это техники так копаются? Наконец-то поступает известие - данные по обоим каналам недоступны.
Произошло то, что не имело права произойти! С анализом можно подождать, нет времени на размышления о причинах - необходимо перейти на аварийный режим работы с одним серверам. Однако страховое копирование не было лишь потерей времени. Переконфигурация - вот твоя задача, закажешь термос кофе, выключишь телефон и «набираешь обороты». Самое худшее уже позади, ты с удовольствием допиваешь остатки кофе и запускаешь сеть в аварийном режиме. Все в порядке /Уф-ф/. Только что же они все как с ума посходили? Ты смотришь на часы и начинаешь кое-что понимать.
Начало третьего. Это значит, что в течение 6 часов несколько десятков человек в фирме были лишены доступа к информации. Все бы ничего, но по правде говоря, можно было бы всех их послать на это время домой - по крайней мере выспались бы. На следующий день ты пробуешь прикинуть убытки, возникшие из-за неполадки, и волосы у тебя встают дыбом...
Мы предоставляем читателю судить, является ли вышеприведенный текст лишь фантазией. В любом случае истиной является то, что сохранность данных и обеспечение доступа к ним - две большие разницы. В каждой сети, независимо от встроенных в них систем сохранения данных, имеются два слабых места: основная плата сервера и его устройство питания. При их повреждении заменить эти элементы не сложно, но эта работа требует времени, особенно, если пользователь не может выполнить ее самостоятельно.
В большинстве случаев применение SFT Level III полностью разрешило бы все проблемы, но у него только один недостаток - он не существует.
Кроме того, в случае, когда осторожный администратор позаботился о запасном компьютере, который при необходимости мог бы заменить сервер, конфигурирование со страховых лент осуществить отнюдь не просто, тем более быстро. Минимизация времени, необходимого на повторный запуск сети после аварии сервера, а также полное исключение необходимости вмешательства пользователя в аппаратное обеспечение лежат в основе простой, но эффективной концепции сохранения данных, которую я хотел бы показать ниже. Вся идея во всей ее простоте представлена на рис. 1 и 2.
Как видно из этих рисунков, эта идея касается двухсерверных сетей. Конфигурации такого типа достойны самых горячих рекомендаций, но предметом статьи являются не их преимущества, мы затронем их в другой раз. Вернемся к нашей концепции. Она основывается прежде всего на подключении к каждому из серверов дополнительных жестких дисков. Количество и емкость этих дисков должны выбираться таким образом, чтобы стало возможным производить перекрестное копирование томов. Такое собственно перекрестное сохранение данных заключает в себе само существо идеи: ежедневно копируется полная структура и содержимое томов сервера 1 на дополнительные диски сервера 2 и наоборот, активные диски сервера 2 копируются на дополнительные диски сервера 1. Эффект очевиден: реакция на аварию одного из серверов заключается в выключении на какое-то время из сети и почти сразу же - включении системы с одним активным сервером. Я пишу "почти", так как сначала необходимо в аварийный режим работы сети ввести сохранение протоколов работы.
Наиболее простым образом это можно выполнить, если их сохранением управляет системный сценарий начала сеанса и на случай аварийного сбоя мы заранее подготовим аварийный файл, который достаточно будет соответствующим образом переименовать. Процесс обеспечения сохранности диска может быть полностью автоматизирован и осуществиться, например, ночью на одной из рабочих станций при помощи простого датчика времени. Сам процесс обеспечения сохранности должен быть хорошо продуман. Станция, на которой осуществляется копирование дисков, может работать с любым пользователем, и даже злостное с ней манипулирование на самом деле может оказаться не фатальным. Опытный администратор справится с этой работой без особых хлопот.
Преимущества описанного выше способа обеспечения непрерывности работы в сети очевидны. Недостатком же является жесткое ограничение в распоряжении объемами памяти серверов. Например, следует помнить, что одна прикладная программа всегда может пользоваться денными с одного сервера, в противном случае в аварийном режиме может иметь место внутренняя несовместимость, когда часть данных «опаздывает» с возвратом в нужное состояние с момента последнего обеспечения сохранности.
Критически настроенный читатель может подумать, что раз у нас имеется два сервера, то можно было бы не копировать постоянно полное содержимое одного сервера на
другой, аварийный, а воспользоваться, например, программой LanShadow.
Это так, но иногда нормальная работа сети проходит фактически на базе только одного сервера, и, кроме этого, внутренняя совместимость данных на случай аварии не обеспечивается, ведь LanShadow копирует только закрытые файлы.
Все это время мы предполагаем, что серверы работают все время без перерыва. Здорово! Проблемы "выключать, или не выключать" не существует! Ведь механические устройства (диски) и электроника подвергается наибольшим нагрузкам в момент запуска и при нагреве (или остывании) системы (пики напряжения!). Стабильность условий - это самый серьезный аргумент для работы в постоянном режиме.
Следует помнить, что все, описанное выше, может использоваться как способ, дополняющий другие механизмы, и ни в коем случае не заменяет собой традиционных подходов к проблемам обеспечения сохранности данных, таких, как зеркальная запись на диски или дублирование. В связи с этим отказ от регулярного применения стриммера и сохранения лент в безопасном месте был бы по меньшей мере легкомысленным.
Будем, помнить, что небольшой пожар в помещении, где находятся серверы, можно погасить одним огнетушителем, тогда как связанная с ним потеря данных может означать собой крах не одной, а нескольких фирм.
Славомир Зданович (S. Zdanapicz)
-----
Оригинал:
Журналы: ReadMe N2/1993 год, Обложка
Статья:
Из воспоминаний старого администратора
Или о том, как избежать забот
Мартовское утро. Начало рабочего дня. За окном холодно, безлюдно и сонно. Ты садишься за письменный стол, завариваешь кофе и знаешь, что этих чашек кофе будет еще много... Звонит телефон. Голос коллеги сообщает, что у нее что-то не получается с выходом в сеть. Слава богу, что хоть что-то происходит, небольшая прогулка к серверам хоть немного тебя освежит. При следующем телефонном звонке ты уже не поднимаешь трубку, жаль времени, ведь как всегда-«проблемы с выходом в сеть».
Ты бесстрашно подходишь к серверам. Ты знаешь, что ты-хороший специалист, в твоем распоряжении кроме обычных средств - NetWare 3.11, источники бесперебойного питания, дуплексы, система архивирования - в общем, спокойствие полное.
Опыт тебя научил, что катастрофы происходят только с другими. Смотришь на дисплей первого сервера и не веришь своим глазам: «SYSTEM HALTED»! В кровь поступает доза адреналина! Сонливость исчезает без следа. Нужно действовать! Система просит разрешения для записи диагноза на дискету - пусть записывает. Холодная дрожь в плечах, сервер не реагирует. Зависание сервера - это не пустяк, но в то же время и не катаклизм. Последнее сообщение на экране успокаивает, что повторный запуск системы произойдет после повторного включения питания. С биением сердца ты включаешь сервер и ждешь.
Ожидая, ты думаешь об общих теориях сохранности данных, о том, кок хорошо, что у тебя есть второй сервер, а особенно-стриммер, о котором ты всегда думал как об устройстве сохранения скорее для самоуспокоения, чем как о реальном, полезном оборудовании. Ты дожидаешься и знаешь, «что тебе хорошо, но не безнадежно». Сервер не работает - сигнализация об ошибке от первого DCB.
Ничего не поделаешь, это железо, работа для техников. Телефон не умолкает, это нормально, все нетерпеливы. Время идет. У тебя есть второй сервер и страховые ленты с первого, но переконфигурация сети в односерверную занимает много времени, а фирма без информации жить не может. Ты думаешь о дуплексном режиме - ведь делать-то что-то надо! Достаточно локализовать ошибку, потом сервер заработает на одном канале. И почему это техники так копаются? Наконец-то поступает известие - данные по обоим каналам недоступны.
Произошло то, что не имело права произойти! С анализом можно подождать, нет времени на размышления о причинах - необходимо перейти на аварийный режим работы с одним серверам. Однако страховое копирование не было лишь потерей времени. Переконфигурация - вот твоя задача, закажешь термос кофе, выключишь телефон и «набираешь обороты». Самое худшее уже позади, ты с удовольствием допиваешь остатки кофе и запускаешь сеть в аварийном режиме. Все в порядке /Уф-ф/. Только что же они все как с ума посходили? Ты смотришь на часы и начинаешь кое-что понимать.
Начало третьего. Это значит, что в течение 6 часов несколько десятков человек в фирме были лишены доступа к информации. Все бы ничего, но по правде говоря, можно было бы всех их послать на это время домой - по крайней мере выспались бы. На следующий день ты пробуешь прикинуть убытки, возникшие из-за неполадки, и волосы у тебя встают дыбом...
Мы предоставляем читателю судить, является ли вышеприведенный текст лишь фантазией. В любом случае истиной является то, что сохранность данных и обеспечение доступа к ним - две большие разницы. В каждой сети, независимо от встроенных в них систем сохранения данных, имеются два слабых места: основная плата сервера и его устройство питания. При их повреждении заменить эти элементы не сложно, но эта работа требует времени, особенно, если пользователь не может выполнить ее самостоятельно.
В большинстве случаев применение SFT Level III полностью разрешило бы все проблемы, но у него только один недостаток - он не существует.
Кроме того, в случае, когда осторожный администратор позаботился о запасном компьютере, который при необходимости мог бы заменить сервер, конфигурирование со страховых лент осуществить отнюдь не просто, тем более быстро. Минимизация времени, необходимого на повторный запуск сети после аварии сервера, а также полное исключение необходимости вмешательства пользователя в аппаратное обеспечение лежат в основе простой, но эффективной концепции сохранения данных, которую я хотел бы показать ниже. Вся идея во всей ее простоте представлена на рис. 1 и 2.
Как видно из этих рисунков, эта идея касается двухсерверных сетей. Конфигурации такого типа достойны самых горячих рекомендаций, но предметом статьи являются не их преимущества, мы затронем их в другой раз. Вернемся к нашей концепции. Она основывается прежде всего на подключении к каждому из серверов дополнительных жестких дисков. Количество и емкость этих дисков должны выбираться таким образом, чтобы стало возможным производить перекрестное копирование томов. Такое собственно перекрестное сохранение данных заключает в себе само существо идеи: ежедневно копируется полная структура и содержимое томов сервера 1 на дополнительные диски сервера 2 и наоборот, активные диски сервера 2 копируются на дополнительные диски сервера 1. Эффект очевиден: реакция на аварию одного из серверов заключается в выключении на какое-то время из сети и почти сразу же - включении системы с одним активным сервером. Я пишу "почти", так как сначала необходимо в аварийный режим работы сети ввести сохранение протоколов работы.
Наиболее простым образом это можно выполнить, если их сохранением управляет системный сценарий начала сеанса и на случай аварийного сбоя мы заранее подготовим аварийный файл, который достаточно будет соответствующим образом переименовать. Процесс обеспечения сохранности диска может быть полностью автоматизирован и осуществиться, например, ночью на одной из рабочих станций при помощи простого датчика времени. Сам процесс обеспечения сохранности должен быть хорошо продуман. Станция, на которой осуществляется копирование дисков, может работать с любым пользователем, и даже злостное с ней манипулирование на самом деле может оказаться не фатальным. Опытный администратор справится с этой работой без особых хлопот.
Преимущества описанного выше способа обеспечения непрерывности работы в сети очевидны. Недостатком же является жесткое ограничение в распоряжении объемами памяти серверов. Например, следует помнить, что одна прикладная программа всегда может пользоваться денными с одного сервера, в противном случае в аварийном режиме может иметь место внутренняя несовместимость, когда часть данных «опаздывает» с возвратом в нужное состояние с момента последнего обеспечения сохранности.
Критически настроенный читатель может подумать, что раз у нас имеется два сервера, то можно было бы не копировать постоянно полное содержимое одного сервера на
другой, аварийный, а воспользоваться, например, программой LanShadow.
Это так, но иногда нормальная работа сети проходит фактически на базе только одного сервера, и, кроме этого, внутренняя совместимость данных на случай аварии не обеспечивается, ведь LanShadow копирует только закрытые файлы.
Все это время мы предполагаем, что серверы работают все время без перерыва. Здорово! Проблемы "выключать, или не выключать" не существует! Ведь механические устройства (диски) и электроника подвергается наибольшим нагрузкам в момент запуска и при нагреве (или остывании) системы (пики напряжения!). Стабильность условий - это самый серьезный аргумент для работы в постоянном режиме.
Следует помнить, что все, описанное выше, может использоваться как способ, дополняющий другие механизмы, и ни в коем случае не заменяет собой традиционных подходов к проблемам обеспечения сохранности данных, таких, как зеркальная запись на диски или дублирование. В связи с этим отказ от регулярного применения стриммера и сохранения лент в безопасном месте был бы по меньшей мере легкомысленным.
Будем, помнить, что небольшой пожар в помещении, где находятся серверы, можно погасить одним огнетушителем, тогда как связанная с ним потеря данных может означать собой крах не одной, а нескольких фирм.
Славомир Зданович (S. Zdanapicz)
-----
Оригинал:
