Переводы — Десять советов для увеличения производительности сети
Отслеживать и ликвидировать проблемы с быстродействием сети непросто. Повышение эффективности работы сети — больше, чем просто задача определения непонятных узких мест, оно требует практически сверхъестественного понимания организации информационных операций и крепких нервов для противостояния возникшим проблемам.
Чтобы убрать помехи в сети, мы выделили 10 областей, при настройке которых, а также с небольшими вложениями можно добиться значительного прироста производительности.
Всё больше и больше компаний пытаются использовать сети в бизнесе, так что будьте уверены - это дополнительное конкурентное преимущество для вашей фирмы.
Совет No. 1: Ускорьте WAN
В IT долгое время использовались выделенные линии и дорогостоящие мощности WAN. Сайты объединялись линиями T1, MPLS и, даже использовалась ретрансляция кадров, только для того, чтобы обеспечить соединение. Но времена изменились. Не спешите проклинать счета за WAN, рассмотрите альтернативы.
Cogent Communications — один из провайдеров с наибольшим покрытием сетью территории США. Подключение к такой сети означает существенный прирост пропускной способности от сайта к сайту при одновременной экономии средств. Все это — вопрос топологии. Объединение даже небольшого количества сайтов одной WAN позволит сэкономить средства для увеличения пропускной способности канала к сайтам, не вошедшим в эту сеть.
Вам больше не потребуется VPN соединение между сайтами. При условии хорошего договора и низких задержек в сети никаких проблем не возникнет. Преимущества стомегабитного канала между вашими сайтами снизят расходы на WAN вдвое.
Сайты вне мощностей крупных провайдеров, оставшиеся на выделенных линиях, в обозримом будущем тоже могут получить пользу от ускорения WAN — например, при помощи Riverbed's Steelhead (см. the InfoWorld Test Center's hands-on review of Riverbed Steelhead (англ.)). Если вы не можете увеличить пропускную способность канала к этим сайтам, единственным решением может быть только уменьшение трафика без снижения его эффективности. Вот тут и могут помочь инструменты для оптимизации WAN.
Совет No. 2: Избавляйтесь от выделенных линий
Ваш главный офис в Сахаре? Если нет, то пора избавиться от доступа к сети через выделенные линии. Подключение к Time Warner Business Class, Comcast Business Class, и FiOS — лучший и наиболее дешёвый способ получить высокоскоростной интернет. Вместо существующих сетей T1 можно получить десятикратное увеличение пропускной способности, причём это будет дешевле и надежней.
Согласен, выделенные линии Т1 и Т3 имеют меньшие задержки, но их стоимость заоблачна, и решения на их основе ограничены (особенно это касается решений бизнес-класса). Пора сказать вашему провайдеру, что вы отключаете SmartJacks и выбираете что-то получше.
Медленный доступ в Интернет — всегда главная причина жалоб пользователей. Дайте им ту скорость, которую они могут получать дома, и они успокоятся.
Совет No. 3: Откройтесь новому
Многие компании цепляются за устаревшие решения, нагрузив IT дорогостоящими ресурсоёмкими задачами по внедрению старых платформ в новые инфраструктуры. Вот как запустить новую архитектуру VMware vSphere под древней Windows NT4?
Не цепляйтесь за прошлое. Это влияет на стоимость, снижает время работы, а бизнес -системы становятся неустойчивыми.
Вместо того, чтобы продолжать возиться с установкой систем десятилетней давности на новую инфраструктуру, выкиньте их и попробуйте что-то новое. Возможно, сначала это будет стоить больше, но в долгосрочной перспективе оно окупится за счёт того, что не придётся связываться с устаревшими системами.
В данном случае личное мнение влияет на ситуацию не слабее технического аспекта. В IT всегда есть те, кто смотрит на всё через призму любимых технологий, отвергая факты. Не всегда просто привести людей во тьме ночного шторма к новой технологии. Помните, что цепляться за зацикленного на цели задачи исправления системного администратора может быть так же губительно, как цепляться за устаревшие технологии.
Совет No. 4: Создайте стенд
Оправданий не бывает. Можно собрать очень мощный стенд по цене сервера. Дорогой, двухпроцессорный, на базе 12-ядерного AMD Istanbul, сервер в 1 unit способен запускать несколько дюжин виртуальных машин для тестирования примерно за $1500. Используя VMware Server на Linux или VMware ESXi, можно избежать проблем с лицензиями, собирая отличную платформу для тестирования всего — от обновления ПО до новых пакетов, новых ОС или даже сетевых архитектур.
Комбинируя сервер виртуализации с такими инструментами, как GNS3, вы можете собирать и запускать практически любую желаемую сеть или инфраструктуру. Нет способа проще определить узкие места, чем в тестовом стенде, и, если этот стенд просто конструируется при помощи сервера с виртуальными машинами, то отказываться от него смысла нет. Более того, с виртуальной лабораторией вы можете подобрать требуемые конфигурации конкретных серверов, определить требуемые ресурсы памяти и процессора для работы под ожидаемыми (и неожидаемыми!) нагрузками. Это убережёт от лишних затрат ресурсов.
Совет No. 5: Следите за всем
Мониторинг сети и систем — дедушка диагностики узких мест. Когда пользователи жалуются, что сеть медленная, обычно для решения проблем в ней ничего нет. Но пока у вас нет инструментов для того, чтобы можно было увидеть, где конкретно проблема, вам придётся охотиться за решением во тьме.
Предпочитаете ли вы проприетарные инструменты, или свободные — есть мириады доступных опций для наблюдения за всем: от сетевых задержек, загрузки памяти и процессора до быстродействия SAN и длины очередей к дисками — вы укажете, что именно нужно.
Наблюдать можно за всем, что существует. Если за чем-то можно наблюдать — это можно отобразить графически. Если что-то может быть графически отображено — есть хороший шанс, что простой взгляд на график результатов может указать верный путь, тогда вы легко определите проблему без лишних усилий.
Во время настройки мониторинга сети, будьте уверены, что переворошили всё, что только можно. Следите за загрузкой процессоров роутеров и свитчей; наблюдайте за ошибками сетевых интерфейсов; логи роутеров и свитчей должны собираться логи на централизованные серверы. Анализируйте эти логи, ведь вам следует знать о любой ошибке — от конфликтов IP до отказа цепей. Внимательная, вдумчивая реализация и настройка мониторинга сэкономит массу времени и сил — особенно, если следить за всем.
Совет No. 6: Знайте используемые программы
Пока что вы получили только наблюдение за быстродействием инфраструктуры. Все компьютерные мощности и ресурсы хранения информации в сети используются программами. Для слишком многих из нас эти программы подобны чёрной дыре — мы можем легко наблюдать результаты их работы в нашей инфраструктуре, но часто тяжело понять, что же происходит при их работе.
Часто при приобретении ПО, разработчики сами его устанавливают и интегрируют в сеть. В результате отделу IT почти ничего делать не нужно. Но будьте осторожны — вы попадаете в ловушку в случае возникновения проблем с сетью.
Потратьте время и найдите слабые места в используемых программах. Будь то затратными хранимыми процедурами баз данных при логине пользователя или масштабное замедление системы во время начала бэкапов — вы должны знать заранее, когда может снизиться производительность.
Для проверки вам придется сделать тесты программ в инфраструктуре до их приобретения. Обращайте внимание на то, сколько ресурсов используется для теста и какие мощности требуются при реальных нагрузках. Такой вид тестирования может приоткрыть недостатки архитектуры программы, которые могут сделать невозможным её использование в вашей среде. Лучше знать все заранее, прежде чем пользователи с факелами и вилами набросятся на вас.
Совет No. 7: Терабайты и количество шпинделей
За последние несколько лет ёмкость дисков значительно возросла. С появлением 2 Тб SATA дисков стало возможным поместить в один двухъюнитовый сервер более, чем 10 Тб. И это замечательно — ведь требуется меньше дисков, верно? Не спешите с выводами.
Вы должны понимать, что у нынешних SATA-дисков и их сородичей с меньшей емкостью есть общая особенность: они одинаково быстрые. Пока возможно втиснуть 2Тб данных на один SATA-диск на 7,200 rpm, вы будете ограничены временем среднего случайного доступа в 80 возможных IOPS (I/O operations per second) на диск. Если вы не храните статические данные, то готовьтесь к падению быстродействия в сравнении с вдвое большим числом дисков в 1Тб.
Если ваши программы требуют большого количества операций случайного чтения или записи (базы данных и почтовые сервера обычно попадают в эту категорию), то вам нужно много отдельных дисков для получения приемлемой скорости транзакций. В то время, как большие диски используются для хранения не особо часто используемых данных, наиболее ценные данные должны располагаться на массивах из небольших быстрых дисков.
Cовет No. 8: Не помещайте десятифунтовый сервер в сумку на пять фунтов.
Виртуализация — наверное, самая замечательная вещь, появившаяся в корпоративных датацентрах за долгое время. Она позволяет сделать управление и мониторинг удобней, улучшить масштабируемость, упростить восстановление после сбоев и блестяще уменьшает количество требуемых физических серверов, пожирающих энергию и испускающих жар.
[ Если нужна иноформация по тому, как лучше организовать виртуализацию, скачайте InfoWorld's Sever Virtualization Deep Dive и InfoWorld's Storage Virtualization Deep Dive ]
Технология виртуализации может всё испортить, если ее использовать неверно. Виртуализация — не волшебство. Она не может сотворить процессор, память или IOPS диска из воздуха.
При росте инфраструктуры виртуализации легко следить за быстродействием процессоров и памяти. Любой гипервизор виртуализации предоставляет возможность увидеть количество доступных для работы ресурсов. Кроме того, лучше следить за быстродействием дисковой подсистемы, нехватка которого может вызвать проблемы при его предельном использовании виртуальными серверами.
Например, у вас есть сто физических серверов, которые нужно виртуализировать. Они обычно простаивают на оборудовании трёхгодичной давности и требуют 1GHz процессора, 1 Гб памяти и быстродействия диска в 250 IOPS.
Вы можете решить, что сервер X5650 с восемью шестиядреными процессорами со 128 Гб памяти способен комфорно работать под такой нагрузкой. Кроме того, у нас же более, чем 20 процентный запас процессоров и памяти, правильно? Все это так, но учтите, что для этого потребуется подключённый оптоволоконный канал (или массив дисков), эквивалентный примерно 140 15,000-rpm дискам по скорости, чтобы выдержать требуемую нагрузку. Не так-то просто определить требуемое быстродействие.
Совет No. 9: Сохранять дубликаты?
При экспонециальном росте данных, естественно искать инструменты, которые могут обуздать использование дорогих дисковых ресурсов. Одним из лучших способов является дедубликация. При её применении на бэкапе и архивации или прямо на главном хранилище появляется значительный выигрыш в затратах ресурсов хранения, полученный удалением дублирующихся данных и использованием только уникальной информации.
Дедубликация великолепна для бэкапов. Если вы её реализуете её в вашей программе создания бэкапов или устройстве (вроде библиотеки виртуальной ленты), то можете потенциально избежать месяцев бэкапов при такой же возможности восстановить всё в нужный момент. Это лучше, чем копаться в поисках ленты каждый раз, когда нужно восстановить что-то позднее дня-двух.
Однако, у всего есть минусы.Есть они и у процесса дедубликации. Основная проблема — она требует много ресурсов. Не удивляйтесь тому, что NetApp, один из нескольких самых крупных разработчиков SAN, предлагает контроллеры увеличения быстродействия в виде своих "Performance Acceleration Modules". Определение и обработка дублирующихся данных требует большого числа ресурсов контроллера. Другими словами, за сохранение свободного места расплачиваешься быстродействием.
Совет No. 10: Делайте бекапы быстрее
Бэкапы почти всегда медленней, чем хотелось бы, и решение проблемы со скоростью чаще искусство, чем наука. Но есть одна общая проблема, с которой администратор бэкапов сталкивается в каком-либо виде.
Если вы делаете бэкапы прямо на ленту, значит, не используете приводы на полную мощность. Текущее поколение стримеров LTO4 (которых в скором времени вытеснят LTO5) теоретически способны обеспечивать скорость записи более, чем в 120 Мб/с, но мало кто видел это в реальности. Чаще всего, это вызвано малым количеством источников, поддерживающих скорость чтения, удовлетворяющую производительность стримера. Например, источник бэкапа, состоящего из пары SAS-дисков в массиве RAID1, предоставляют в тестовых условиях скорость намного большую, но для стандартного копирования файлов по сети через Windows, вы редко увидите скорость, превышающую 60 Мб/с. Поэтому многие стримеры потеряли значительную часть эффективности. По этой причине с быстродействием бэкапов все еще есть проблемы.
Другими словами, проблема не в стримере, а в хранилищах серверов, бэкап которых производится. Несмотря на то, что не так уж и много чего можно сделать без крупных вложений денег на большое и быстрое устройство бэкапа с диска на диск, больше возможностей появляется, если есть SAN. И даже в этом случае многое будет зависить от вида используемого SAN, используемого ПО, хоста производящего бэкап — чтение напрямую с SAN (а не по сети) может быть замечательным решением этой очень неприятной проблемы.
Оригинал (английский): 10 tips for boosting network performance
Перевод: ©
Shtsh, 
Zereal.
Комментарии перевода в личку/джаббер. Zereal
Чтобы убрать помехи в сети, мы выделили 10 областей, при настройке которых, а также с небольшими вложениями можно добиться значительного прироста производительности.
Всё больше и больше компаний пытаются использовать сети в бизнесе, так что будьте уверены - это дополнительное конкурентное преимущество для вашей фирмы.
Совет No. 1: Ускорьте WAN
В IT долгое время использовались выделенные линии и дорогостоящие мощности WAN. Сайты объединялись линиями T1, MPLS и, даже использовалась ретрансляция кадров, только для того, чтобы обеспечить соединение. Но времена изменились. Не спешите проклинать счета за WAN, рассмотрите альтернативы.
Cogent Communications — один из провайдеров с наибольшим покрытием сетью территории США. Подключение к такой сети означает существенный прирост пропускной способности от сайта к сайту при одновременной экономии средств. Все это — вопрос топологии. Объединение даже небольшого количества сайтов одной WAN позволит сэкономить средства для увеличения пропускной способности канала к сайтам, не вошедшим в эту сеть.
Вам больше не потребуется VPN соединение между сайтами. При условии хорошего договора и низких задержек в сети никаких проблем не возникнет. Преимущества стомегабитного канала между вашими сайтами снизят расходы на WAN вдвое.
Сайты вне мощностей крупных провайдеров, оставшиеся на выделенных линиях, в обозримом будущем тоже могут получить пользу от ускорения WAN — например, при помощи Riverbed's Steelhead (см. the InfoWorld Test Center's hands-on review of Riverbed Steelhead (англ.)). Если вы не можете увеличить пропускную способность канала к этим сайтам, единственным решением может быть только уменьшение трафика без снижения его эффективности. Вот тут и могут помочь инструменты для оптимизации WAN.
Совет No. 2: Избавляйтесь от выделенных линий
Ваш главный офис в Сахаре? Если нет, то пора избавиться от доступа к сети через выделенные линии. Подключение к Time Warner Business Class, Comcast Business Class, и FiOS — лучший и наиболее дешёвый способ получить высокоскоростной интернет. Вместо существующих сетей T1 можно получить десятикратное увеличение пропускной способности, причём это будет дешевле и надежней.
Согласен, выделенные линии Т1 и Т3 имеют меньшие задержки, но их стоимость заоблачна, и решения на их основе ограничены (особенно это касается решений бизнес-класса). Пора сказать вашему провайдеру, что вы отключаете SmartJacks и выбираете что-то получше.
Медленный доступ в Интернет — всегда главная причина жалоб пользователей. Дайте им ту скорость, которую они могут получать дома, и они успокоятся.
Совет No. 3: Откройтесь новому
Многие компании цепляются за устаревшие решения, нагрузив IT дорогостоящими ресурсоёмкими задачами по внедрению старых платформ в новые инфраструктуры. Вот как запустить новую архитектуру VMware vSphere под древней Windows NT4?
Не цепляйтесь за прошлое. Это влияет на стоимость, снижает время работы, а бизнес -системы становятся неустойчивыми.
Вместо того, чтобы продолжать возиться с установкой систем десятилетней давности на новую инфраструктуру, выкиньте их и попробуйте что-то новое. Возможно, сначала это будет стоить больше, но в долгосрочной перспективе оно окупится за счёт того, что не придётся связываться с устаревшими системами.
В данном случае личное мнение влияет на ситуацию не слабее технического аспекта. В IT всегда есть те, кто смотрит на всё через призму любимых технологий, отвергая факты. Не всегда просто привести людей во тьме ночного шторма к новой технологии. Помните, что цепляться за зацикленного на цели задачи исправления системного администратора может быть так же губительно, как цепляться за устаревшие технологии.
Совет No. 4: Создайте стенд
Оправданий не бывает. Можно собрать очень мощный стенд по цене сервера. Дорогой, двухпроцессорный, на базе 12-ядерного AMD Istanbul, сервер в 1 unit способен запускать несколько дюжин виртуальных машин для тестирования примерно за $1500. Используя VMware Server на Linux или VMware ESXi, можно избежать проблем с лицензиями, собирая отличную платформу для тестирования всего — от обновления ПО до новых пакетов, новых ОС или даже сетевых архитектур.
Комбинируя сервер виртуализации с такими инструментами, как GNS3, вы можете собирать и запускать практически любую желаемую сеть или инфраструктуру. Нет способа проще определить узкие места, чем в тестовом стенде, и, если этот стенд просто конструируется при помощи сервера с виртуальными машинами, то отказываться от него смысла нет. Более того, с виртуальной лабораторией вы можете подобрать требуемые конфигурации конкретных серверов, определить требуемые ресурсы памяти и процессора для работы под ожидаемыми (и неожидаемыми!) нагрузками. Это убережёт от лишних затрат ресурсов.
Совет No. 5: Следите за всем
Мониторинг сети и систем — дедушка диагностики узких мест. Когда пользователи жалуются, что сеть медленная, обычно для решения проблем в ней ничего нет. Но пока у вас нет инструментов для того, чтобы можно было увидеть, где конкретно проблема, вам придётся охотиться за решением во тьме.
Предпочитаете ли вы проприетарные инструменты, или свободные — есть мириады доступных опций для наблюдения за всем: от сетевых задержек, загрузки памяти и процессора до быстродействия SAN и длины очередей к дисками — вы укажете, что именно нужно.
Наблюдать можно за всем, что существует. Если за чем-то можно наблюдать — это можно отобразить графически. Если что-то может быть графически отображено — есть хороший шанс, что простой взгляд на график результатов может указать верный путь, тогда вы легко определите проблему без лишних усилий.
Во время настройки мониторинга сети, будьте уверены, что переворошили всё, что только можно. Следите за загрузкой процессоров роутеров и свитчей; наблюдайте за ошибками сетевых интерфейсов; логи роутеров и свитчей должны собираться логи на централизованные серверы. Анализируйте эти логи, ведь вам следует знать о любой ошибке — от конфликтов IP до отказа цепей. Внимательная, вдумчивая реализация и настройка мониторинга сэкономит массу времени и сил — особенно, если следить за всем.
Совет No. 6: Знайте используемые программы
Пока что вы получили только наблюдение за быстродействием инфраструктуры. Все компьютерные мощности и ресурсы хранения информации в сети используются программами. Для слишком многих из нас эти программы подобны чёрной дыре — мы можем легко наблюдать результаты их работы в нашей инфраструктуре, но часто тяжело понять, что же происходит при их работе.
Часто при приобретении ПО, разработчики сами его устанавливают и интегрируют в сеть. В результате отделу IT почти ничего делать не нужно. Но будьте осторожны — вы попадаете в ловушку в случае возникновения проблем с сетью.
Потратьте время и найдите слабые места в используемых программах. Будь то затратными хранимыми процедурами баз данных при логине пользователя или масштабное замедление системы во время начала бэкапов — вы должны знать заранее, когда может снизиться производительность.
Для проверки вам придется сделать тесты программ в инфраструктуре до их приобретения. Обращайте внимание на то, сколько ресурсов используется для теста и какие мощности требуются при реальных нагрузках. Такой вид тестирования может приоткрыть недостатки архитектуры программы, которые могут сделать невозможным её использование в вашей среде. Лучше знать все заранее, прежде чем пользователи с факелами и вилами набросятся на вас.
Совет No. 7: Терабайты и количество шпинделей
За последние несколько лет ёмкость дисков значительно возросла. С появлением 2 Тб SATA дисков стало возможным поместить в один двухъюнитовый сервер более, чем 10 Тб. И это замечательно — ведь требуется меньше дисков, верно? Не спешите с выводами.
Вы должны понимать, что у нынешних SATA-дисков и их сородичей с меньшей емкостью есть общая особенность: они одинаково быстрые. Пока возможно втиснуть 2Тб данных на один SATA-диск на 7,200 rpm, вы будете ограничены временем среднего случайного доступа в 80 возможных IOPS (I/O operations per second) на диск. Если вы не храните статические данные, то готовьтесь к падению быстродействия в сравнении с вдвое большим числом дисков в 1Тб.
Если ваши программы требуют большого количества операций случайного чтения или записи (базы данных и почтовые сервера обычно попадают в эту категорию), то вам нужно много отдельных дисков для получения приемлемой скорости транзакций. В то время, как большие диски используются для хранения не особо часто используемых данных, наиболее ценные данные должны располагаться на массивах из небольших быстрых дисков.
Cовет No. 8: Не помещайте десятифунтовый сервер в сумку на пять фунтов.
Виртуализация — наверное, самая замечательная вещь, появившаяся в корпоративных датацентрах за долгое время. Она позволяет сделать управление и мониторинг удобней, улучшить масштабируемость, упростить восстановление после сбоев и блестяще уменьшает количество требуемых физических серверов, пожирающих энергию и испускающих жар.
[ Если нужна иноформация по тому, как лучше организовать виртуализацию, скачайте InfoWorld's Sever Virtualization Deep Dive и InfoWorld's Storage Virtualization Deep Dive ]
Технология виртуализации может всё испортить, если ее использовать неверно. Виртуализация — не волшебство. Она не может сотворить процессор, память или IOPS диска из воздуха.
При росте инфраструктуры виртуализации легко следить за быстродействием процессоров и памяти. Любой гипервизор виртуализации предоставляет возможность увидеть количество доступных для работы ресурсов. Кроме того, лучше следить за быстродействием дисковой подсистемы, нехватка которого может вызвать проблемы при его предельном использовании виртуальными серверами.
Например, у вас есть сто физических серверов, которые нужно виртуализировать. Они обычно простаивают на оборудовании трёхгодичной давности и требуют 1GHz процессора, 1 Гб памяти и быстродействия диска в 250 IOPS.
Вы можете решить, что сервер X5650 с восемью шестиядреными процессорами со 128 Гб памяти способен комфорно работать под такой нагрузкой. Кроме того, у нас же более, чем 20 процентный запас процессоров и памяти, правильно? Все это так, но учтите, что для этого потребуется подключённый оптоволоконный канал (или массив дисков), эквивалентный примерно 140 15,000-rpm дискам по скорости, чтобы выдержать требуемую нагрузку. Не так-то просто определить требуемое быстродействие.
Совет No. 9: Сохранять дубликаты?
При экспонециальном росте данных, естественно искать инструменты, которые могут обуздать использование дорогих дисковых ресурсов. Одним из лучших способов является дедубликация. При её применении на бэкапе и архивации или прямо на главном хранилище появляется значительный выигрыш в затратах ресурсов хранения, полученный удалением дублирующихся данных и использованием только уникальной информации.
Дедубликация великолепна для бэкапов. Если вы её реализуете её в вашей программе создания бэкапов или устройстве (вроде библиотеки виртуальной ленты), то можете потенциально избежать месяцев бэкапов при такой же возможности восстановить всё в нужный момент. Это лучше, чем копаться в поисках ленты каждый раз, когда нужно восстановить что-то позднее дня-двух.
Однако, у всего есть минусы.Есть они и у процесса дедубликации. Основная проблема — она требует много ресурсов. Не удивляйтесь тому, что NetApp, один из нескольких самых крупных разработчиков SAN, предлагает контроллеры увеличения быстродействия в виде своих "Performance Acceleration Modules". Определение и обработка дублирующихся данных требует большого числа ресурсов контроллера. Другими словами, за сохранение свободного места расплачиваешься быстродействием.
Совет No. 10: Делайте бекапы быстрее
Бэкапы почти всегда медленней, чем хотелось бы, и решение проблемы со скоростью чаще искусство, чем наука. Но есть одна общая проблема, с которой администратор бэкапов сталкивается в каком-либо виде.
Если вы делаете бэкапы прямо на ленту, значит, не используете приводы на полную мощность. Текущее поколение стримеров LTO4 (которых в скором времени вытеснят LTO5) теоретически способны обеспечивать скорость записи более, чем в 120 Мб/с, но мало кто видел это в реальности. Чаще всего, это вызвано малым количеством источников, поддерживающих скорость чтения, удовлетворяющую производительность стримера. Например, источник бэкапа, состоящего из пары SAS-дисков в массиве RAID1, предоставляют в тестовых условиях скорость намного большую, но для стандартного копирования файлов по сети через Windows, вы редко увидите скорость, превышающую 60 Мб/с. Поэтому многие стримеры потеряли значительную часть эффективности. По этой причине с быстродействием бэкапов все еще есть проблемы.
Другими словами, проблема не в стримере, а в хранилищах серверов, бэкап которых производится. Несмотря на то, что не так уж и много чего можно сделать без крупных вложений денег на большое и быстрое устройство бэкапа с диска на диск, больше возможностей появляется, если есть SAN. И даже в этом случае многое будет зависить от вида используемого SAN, используемого ПО, хоста производящего бэкап — чтение напрямую с SAN (а не по сети) может быть замечательным решением этой очень неприятной проблемы.
Оригинал (английский): 10 tips for boosting network performance
Перевод: ©
Shtsh, Zereal.Комментарии перевода в личку/джаббер.
Zereal
