Portfast выполняет ещё одну важную функцию, кроме быстрого up'а порта — он уменьшает количество сообщений topology change, которые приводят к стиранию таблиц MAC-адресов во всём коммутируемом сегменте, в результате чего следует флуд unknow unicast. Т.е. при каждом включении/выключении порта конечным пользователем, вы получаете TCN и последующую очистку mac-tables на всех свичах в домене STP/RSTP. Защита от дурака — это BPDU Guard для STP. В RSTP защита встроенная, при получении BPDU на Edge Port он автоматически перестают рассматриваться, как Edge Port и попадает под обычные действия алгоритма RSTP.
>Экономии пора — закончилась. Особенно в вопросе виртуализации >инфраструктур. Если кто-то застрял во времени — его право.
>Единая СХД имеет смысл в составе кластера с поддержкой LM или HA как >минимум. При Standalone-ахитектуре данный подход имеет мало смысла.
Очень сильно заблуждаетесь. Всё зависит от решаемых задач, а конкретно, от стоимости простоя. В нашем случае речь идёт о middle-size businness, если сервисы встанут на сутки, компания не несёт многомиллионых убытков, у нас нет интернет магазина, мы не дата-центр веб хостинга, не атомная станция и не банк. В нашем случае есть два варианта. Платный и бесплатный. Бесплатный — это когда хост ESXi умирает, а это в масштабах малых инсталяций бывает раз в несколько лет, я утром прихожу и перезапускаю машины на резервном хосте ESXi. Платный вариант — это 1700 баксов за сокет и примерно 4000 баксов за вицентр, который будет несколько лет фактически простаивать и может быть, когда-нибудь, в случае отказа, однажды за несколько лет автоматически перезапустит виртуалки на другом хосте ESXi. Что даёт бесплатная инсталляция? ОЧЕНЬ МНОГО — модульность, масштабируемость и огромную гибкость. СХД позволяет перераспределить диски между серверами, гипервизор нивилирует зависимость от железа, получаем легко наращиваемую и очень гибкую систему. Ну и резервирование, с ручным перезапуском, что приемлемо для очень многих задач.
У меня в продакшене ESXi на бесплатных лицензиях, Микрофост мне тоже не нравится, но тем не менее Ваше заявление через чур категорично, в масштабах автора поста держать две ноды на Микрософте — почему бы нет?
Ну, SAS-СХД навроде Вашей считается lo-end устройством, т.е. СХД начального уровня. Она много чего не умеет, например, не поддерживает репликацию на другую СХД.
Ну и кроме этого, у меня ещё есть придирка по терминологии.
Если у Вас на оптике STP, значит это обычный Ethernet и говорить «петля по оптике» некорректно. Петля в терминологии Ethernet означает нежелательное состояние сети, во время которого сеть не работает. Кроме того Вы упоминаете про STP, который собственно и борится с подобными петлями, а значит у Вас петель тем более нет. «Петля по оптике» может быть корректным в отношении технологий Token Ring/FDDI, где сеть строится по принципу Кольцо, по которому гуляет маркер и т.п. Оптика Ethernet на L2 уровне не отличается от витой пары, это обычное соединение например двух коммутаторов. Можно взять и поменять трансиверы и вместо оптики подключить витую пару. Топология не изменилась, изменилась только среда передачи данных, откуда тогда берётся петля? Вы же не говорите про витую пару «петля по витой паре»?
А что за кольцо по оптике? FDDI? Расскажите плз более подробно.
По поводу отказа СХД — не все элементы в СХД дублируются, например, пассивный бэкплейн и SAS-экспандеры, в дешёвых СХД могут быть проблемы с софтом, который реализует failover и много много прочих проблем. Т.е. у Вас обязательно должен быть предусмотрен какой-то резервный план на случай отказа СХД. Я например специально брал сервера с большими корзинами, в крайнем случае можно будет винты просто по серверам раскидать.
А что в данной стандартной схеме разворачивания кластерных решений Вам кажется странным и ненадёжным? По всем пунктам согласен с автором, на выходе — модульное, легко расширяемое решение. Может быть Вы через чур консервативны?
Кластер виртуальных машин и СХД — это модульность и гибкость. Его потом очень легко, удобно и дёшево расширять. А по поводу терминала — что именно Вам неудобно? Сейчас наблюдается общемировая тенденция в сторону виртуальных столов VDI и тонких клиентов. Это централизация ресурсов, обезличивание, экономия и т.п.
Очень странные цены. Это железо или вместе с софтом? Недавно собирали подобное решение на деловском оборудовании, две ноды + СХД с двумя полками, сервер под резервные копии + ленточная библиотека, общий бюджет всего решения 1,3 ляма, контора так же на 200 человек. Общая производительность дисковой примерно 2000 iops, сервера при этом практически на загружены, процессора процентов на 20 максимум. Сейчас в память упёрлись, но с выходом ESXi 5.5 ограничений по памяти больше нет.
Описание в статье WFQ неправильное. WFQ не поддерживает маркировку, при использовании данного метода нельзя определить для пакета очередь. Данный метод производит автоматическую классификацию трафика и разбивает его на потоки. При классификации вычисляется хэш функция, которая учитывает множество параметров, а не только ip-precedence — адреса и порты источника, назначения + tos. Пакеты с разными хэшами попадают в разные очереди. Для каждого значения хэша создаётся автоматически отдельная очередь. Количество очередей ограничено, поэтому при генерации 4096 очередей следующие потоки попадают в уже существующие очереди. Вы говорите, что пакет попадает в ту или иную очередь в зависимости от TOS, но это не так. Два пакета с одинаковым TOS но с разными ip-адресами попадут в разные очереди. WFQ практически неуправляем, единственное воздействие — это TOS. Задавая больший ip-precedence мы уменьшаем у пакетов SQ, это приводит, во-первых, к увеличению доли полосы пропускания для данного потока, во-вторых, уменьшает вероятность дропа пакетов данной очереди при её переполнении. Кроме этого, SQ обратно пропорционален размеру пакета, поэтому, вероятность у маленького пакета быть дропнутым меньше, чем у большого.
А windows 2008 не может этого делать сам? Работать это может следующим образом — когда галку ставим, через VSS, контроллер домена узнаёт, что его бэкапят и делает необходимые манипуляции. Галка не стоит — KD не в курсе, что его бэкапят, в итоге ошибка. Я смутно припоминаю, что где-то читал, что данную проблему пофиксили в более новых ОС, к сожалению, точно уже не помню, возможно ошибаюсь.
VSS гарантирует консистентность горячего бэкапа, т.е. если не поставить указанную галочку, можно получить в бэкапе битую базу. На этом функции VSS заканчиваются. А ошибка USN RollBack не связана с тем, битая база или нет, ошибка связана с данными внутри базы, конкретно, с неккоретным значением USN. Т.е. чтобы при восстановлении из снепшота ошибка не возникала, vsphere должен выполнить некие дополнительные манипуляции по контролю USN, не связанные с технологией VSS. Я проводил свои тесты на vSphere 4.1 с windows 2003, возможно, с тех пор что-то поменялось и был предусмотрен некий функционал по контролю USN при восстановлении из снепшота. Если это так, то мне кажется, было бы правильно рассмотреть это в статье, иначе описание получается неполным, не понятно, как это работает.
USN-Rollback будет возникать даже со включеным VSS, потому что природа этой ошибки ну совершенно не связана с VSS. VSS- это сервис, который всего навсего перед бэкапом заставляет базу данных записать все транзакции на диск, далее БД приостанавливает свою работу, затем создаётся теневая копия тома, на что уходит несколько секунд, Далее БД продолжает свою работу в обычном режиме, а бэкап сливается уже с теневой копии. В VMWare теневая копия не создаётся, а создаётся delta vdmk, при этом исходный vdmk становится доступным на чтение и содержит консистентные данные, что позволяет его скопировать в качестве бэкапа. USN-rollback возникает совершенно в других обстоятельствах и никакх не связан с неконсистентностью базы данных АД. USN-rollback можно получить при использовании бэкапа снятого с выключеной машины. Очень важное условие для возникновения данной ошибки — после бэкапа между двумя КД обязательно должна пройти репликация, для этого достаточно создать учётную запись на одном из них. Если этого не сделать, ошибка не появится. Если после этого восстановить один из КД, то он будет с меньшим значением USN, чем USN, который знает оставшийся КД. В итоге будет ошибка. Причём я эту ошибку миллион раз симулировал используя снепшоты VMWare. Избежать этой ошибки можно только одним способом — сделать неавторитетное восстановление, что умеет делать только спец софт, а вот снепшоты VMWare даже с поддержкой VSS этого делать не умеют.
Если Вы имеете в виду ленты в том качестве, когда они использовались как единственный накопитель для ПК типа Спектрума — то да, согласен. Но если говорить в целом, то ленты занимают свою определённую нишу, в которой являются мейнстримовой технологией — долговременное офлайновое хранилище больших объёмов данных.
Да, очень часто. Писать бэкапы на ленты — это стандарт де-факто в любых более менее развитых инфраструктурах по хранению данных. Сейчас пытаются переходить на диски, но пока о какой-то дисковой революции говорить не приходится. Писал выше, что запланированы стандарты LTO-7 и LTO-8, а значит, лента умирать не собирается, по крайней мере в ближайшее время.
Цена золота не соотвествует его полезности. Если брать просто полезность золота, как материала, оно бы стоило в десятки раз дешевле, нежели оно стоит, когда рассматривается в качестве всеобщего обменного эквивалента.
вот ещё мысль про якобы ценность золота и отсуствие таковой у биткоинтов. Можно рассмотреть следующую аналогию, которая ставит под сомнение данное утверждение и показывает, что хэши настолько же ценны и материальны, как и золото. Золото — это некая конфигурация электронов и нуклонов. Хэш в системе биткоинтов — точно такая же конфигурация электроннов и нуклонов, которые представляют атомы жёсткого диска, где лежит кошелёк с биткоинтами. Ценность золота — сложность получения указанной конфигурации нуклонов и электронов. Это возможно либо прямой добычей существующих материалов либо с помощью атомных реакций. Прямая добыча биткоинтов не возможна по первому варианту, т.к. изначально материала такого не существует. Добыча биткоинтов — вычисление хэшей, что в физическом мире выражается в создании сложнонамагниченых участков на жёстком диске. Ферма по добыче битконитов — это фабркиа по намагничиванию ферритовых платин жёсткого диска. Сложность технологического процесса сродни сложности добычи золота.
Хэш точно так же является материальной сущностью, попробуйте его вручную посчитать, поймёте, насколько это сложная задача. То что золото имеет какую-то ценность — это стереотип, привычка восприятия. У золота нет никаких особенных преимуществ перед хэшами.
Мне рассказывал руководитель одной крупной организации, которая прошла проверку РосКомНадзора, что после проверки они выключили все СЗИ, потому что с ними ничего не работает. Цель создания ФЗ-152 совершенно не благостная, не о какой фактической реальной защите речь не идёт, применяемые технические методики в контексте упомянутого закона — пустая, недееспособная формальность, фикция. Практически все требования по закону не технические, а бюррократические. Проверка РосКомНадзора 90% времени изучает журналы, модель угроз и прочее, а АРМ даже не смотрит и терминация защищённых VLANов им абсолютно не интересна. Цель закона — это очередной способ оказывать давление на частный бизнес. Там настолько свободные интерпретации по каждому пункту, что при заинтересованности со стороны проверяющих можно нагнуть любую компанию. Люди пишут письма по разъяснениям, ФСТЭК каждый раз даёт противоречивые, взаимоисключающие комментарии. Это узаконеное вымагательтсво, искуственно созданая отрасль, не удивлюсь, если это лобби производителей СЗИ и безопасников. Большинство компаний не смогут самостоятельно закрыться по закону, т.к. для этого нужна лицензия и обученный персонал по ИБ, им придётся обращаться к подрядчикам, а это бабки бабки бабки. Это всё настолько бредово, что некоторые просто предпочитают платить штрафы, благо они пока не большие.
>Единая СХД имеет смысл в составе кластера с поддержкой LM или HA как >минимум. При Standalone-ахитектуре данный подход имеет мало смысла.
Очень сильно заблуждаетесь. Всё зависит от решаемых задач, а конкретно, от стоимости простоя. В нашем случае речь идёт о middle-size businness, если сервисы встанут на сутки, компания не несёт многомиллионых убытков, у нас нет интернет магазина, мы не дата-центр веб хостинга, не атомная станция и не банк. В нашем случае есть два варианта. Платный и бесплатный. Бесплатный — это когда хост ESXi умирает, а это в масштабах малых инсталяций бывает раз в несколько лет, я утром прихожу и перезапускаю машины на резервном хосте ESXi. Платный вариант — это 1700 баксов за сокет и примерно 4000 баксов за вицентр, который будет несколько лет фактически простаивать и может быть, когда-нибудь, в случае отказа, однажды за несколько лет автоматически перезапустит виртуалки на другом хосте ESXi. Что даёт бесплатная инсталляция? ОЧЕНЬ МНОГО — модульность, масштабируемость и огромную гибкость. СХД позволяет перераспределить диски между серверами, гипервизор нивилирует зависимость от железа, получаем легко наращиваемую и очень гибкую систему. Ну и резервирование, с ручным перезапуском, что приемлемо для очень многих задач.
Ну и кроме этого, у меня ещё есть придирка по терминологии.
Если у Вас на оптике STP, значит это обычный Ethernet и говорить «петля по оптике» некорректно. Петля в терминологии Ethernet означает нежелательное состояние сети, во время которого сеть не работает. Кроме того Вы упоминаете про STP, который собственно и борится с подобными петлями, а значит у Вас петель тем более нет. «Петля по оптике» может быть корректным в отношении технологий Token Ring/FDDI, где сеть строится по принципу Кольцо, по которому гуляет маркер и т.п. Оптика Ethernet на L2 уровне не отличается от витой пары, это обычное соединение например двух коммутаторов. Можно взять и поменять трансиверы и вместо оптики подключить витую пару. Топология не изменилась, изменилась только среда передачи данных, откуда тогда берётся петля? Вы же не говорите про витую пару «петля по витой паре»?
По поводу отказа СХД — не все элементы в СХД дублируются, например, пассивный бэкплейн и SAS-экспандеры, в дешёвых СХД могут быть проблемы с софтом, который реализует failover и много много прочих проблем. Т.е. у Вас обязательно должен быть предусмотрен какой-то резервный план на случай отказа СХД. Я например специально брал сервера с большими корзинами, в крайнем случае можно будет винты просто по серверам раскидать.