All streams
Search
Write a publication
Pull to refresh
28
0

User

Send message
С жидкостями в самолет не пускают, насколько мне известно.
Один вопрос: неужели никто из Вас не берет с собой дезодорант/парфюм/зубную пасту? Как же Вы их тогда в ручной клади проносите?
P.S. Летаю 4-5 раз в год, ни разу проблем с багажом не было.
То что запоздал — согласен.
Но учтите, что осталось еще ОГРОМНОЕ количество мелких организаций, которые используют WSS идущий с SBS и даже не знают о возможности такого апгрейда :)
Несколько внутренних проектов компании в которой я работал/консультировал (по большей части трейдерское и банковское ПО). Под high-load я подразумеваю реальный high-load — базы объемом > 1 Tb, около 300-500 единовременных обращений к базам.
Также был Sharepoint, но тут нагрузка чуть поменьше, и 1С (тоже менее нагруженный).
Я в Syberia провожу 6 часов в день. Вообще никакого дискомфорта.
Да, модули самописные (писал не я, я только ТЗ ставил).
Про AppFabrik Caching к сожалению ничего особенного сказать не могу — не работал тесно с ним.

Касательно NLB — при высоких нагрузках оправданно. Виндовый NLB или решение на базе HaProxy и RHEL вроде работают, иногда даже неплохо, но при высоких нагрузках прирост производительности значительный (мы используем Cisco Arrowpoint). А использование MS NLB вообще не рекомендую — он всего лишь эмулирует балансинг, занимаясь спуфингом MAC адресов.
Но, imho, использование еще чего-то сверху (дополнительные реверс-прокси или чрезмерная балансировка) не нужна. Т.к. если Вы осознаете, что Вам это нужно, то лучше наращивать железные мощности, чем усложнять телеком-инфраструктуру.

Если шаред стореджа нет — то есть еще один выход помимо DFS (но я думаю, стореджа нет т.к. финансирования нет, тогда мой выход не подойдет) — физические FC/iSCSI стораджи с репликацией между собой. Это, кстати, крутой выход, когда используются гео-кластера.
Быстро и просто — никак. Я естественно подразумеваю что Вы уже используете встроенные механизмы, такие как внутренние кэши (кэш вывода и пр.), а также модули сжатия. Ну или если смотреть в большем масштабе, то балансировку нагрузки.
Основными методами оптимизации нагрузки явялется замена/добавления пользовательских функций оптимизации.
У себя мы используем несколько модулей, которые позволяют кэшировать часто-используемые данные в памяти.
Помимо всего — старайтесь ограничивать количество потоков работы с БД. Это позволит обсепечить изоляцию сбоев.

Касательно масштабирования — можете пояснить масштабирование чего Вы подразумеваете? Серверов/приложений/модулей?

Относительно shared — однозначно нет ручной репликации. Слишком много побочных трудозатрат на валидирование и мониторинг. Учитывая возможности, которые нам дает Windows 2012 — лучше отказоусточивая сетевая шара. Такое решение проще администрировать, а все, что проще администрировать — надежнее. Плюс мы убираем одно звено в цепи — DFSR.
High-load MSSQL, комплексная структура (50+ сайтов, 10+ доменов) AD forest, high-load IIS, high-load MS Exchange, сертификация Microsoft (MCSA, MCTS, MCITP, MCP, MCM)
Ваше нет-фу сильно :) Прекрасная статья, будет полезна как начинающим, так и опытным сетевикам/администраторам.
Меня волнует другой вопрос: а как 8ка на мобильном устройстве то?
Аппаратное зеркало. С батарейной поддержкой кэша на контроллере. Без использования Always Write Back (плохо, но батарейная поддержка спасает). У самого контроллера 1 Гб кэша.
Производительность без TRIM приемлемая — при продолжительной записи производительность за 2 часа (на большее не тестировали) падает с 560 Мбайт/с до 150-200 Мбайт/с. Что всяко быстрей SAS.
У нас такая схема, используем зеркало + 3ий диск всегда стоит в Hot Spare Standby + 4ый диск всегда лежит в ящике. Работает уже 1.5 года, за это время 1 раз диск умирал, меняли, вендор заменил по гарантии.
К примеру у этих 4х компаний мог быть собственный старый Exchange (2003) у каждой или другая платформа, типа Communigate. Этот сценарий вполне реален, скажу более, я был свидетелем таких сценариев.
У нас с Вами разные понятия об экономии.Представьте себе 4 организации в холдинге. Каждая > 5000 пользователей (ящиков Exchange).
Что дешевле: разнести и сделать отказоустойчивость для 1 Exchange-массива из раздельных CAS, MB, EDGE, приобрести на это все лицензии и запустить в эксплуатацию, или то же самое, но для 4 массивов?
Учтите, что в последнем случае кластеры будут вообще разненсены логически и географически. Соотв. придется использовать отдельные дисковые полки и т.д.
А, к Вашему сведению, только 1 Tb места на сторадже стоит около 35000 $ для организации (имеется ввиду дублирующиеся Storage, FC, RAID10, включая обслуживание, электроэнергию и все накладные расходы).

P.S. О Вашей практике — это лично у Вас. У нас он используется процентов на 90.
1) Exchange-хостинг. Зачем? Деньги зарабатывать.
2) Предоставление Exchange-ящиков в пакете услуг от системного-интегратора (для небольших и средних компаний).
3) Экономия средств при внедрении Exchange для нескольких обособленных организаций с одним IT-отделом (холдинги и т.д.).

Ну а почему Exchange, а не другой почтовый сервер — тут объяснить сложно. Сугубо мое личное мнение — все остальное работает либо плохо, либо функционала там 1/10 от того, который предоставляет Exchange.
Да и поверьте мне — спрос есть :)
А это gross или net?
И как-то низко для Москвы…
Я не старший (скажем так: средний) Windows-админ, но получаю net несколько больше, чем max в таблице. При этом Senior у нас получают еще больше…

Да и вообще рынок предлагает больше сейчас
Я действительно не понимаю для чего платить деньги за курсы.
Все, что Вы описали прекрасно усваивается после прочтения Self-Prepare книжек 70-640, 642 и 432. Ну может потребуется еще просмотр каких-нибудь видео типа CBT Nuggets.

Мне вполне успешно удавалось и удается за месяц подгатавливаться и сдавать 1 экзамен.

P.S. Возможно я не могу понять людей, которые не могут без ментора усваивать информацию.
Вообще это сильно зависит от организации, где работает специалист (и от «морали» самого спеца).
Но мне бы руки 100% оторвали за отключение файрвола.
Зачем отключать файрвол?! IMHO Нельзя в руки давать управление инфраструктурой тем, кто просто выключает файрвол.
Или использовать софт, который это делает.
Помоему Best Practice считается отключение untagged vlan (если быть точнее — соотв. порта) при использовании тегированного варианта.
Я правильно понимаю, что в таком случае эта фича (а imho это именно фича) не «прокатит»?

Information

Rating
Does not participate
Location
California, США
Registered
Activity