что такое клиентская сеть
Клиент-серверная архитектура в картинках
Знакомая картинка? А вы ведь постоянно сталкиваетесь с этой архитектурой — когда покупаете билет в кино онлайн, бронируете путевку на море или записываетесь к врачу.
На клиент-серверной архитектуре построены все сайты и интернет-сервисы. Также ее используют десктоп-программы, которые передают данные по интернету. Поэтому ИТ-специалисту нужно понимать, что это такое и как работает.
Об этом я и расскажу в статье. Объясню на пальцах, с примерами и забавными картинками =) Если вы больше любите видео-формат, можно посмотреть мой ролик на youtube на ту же тему.
Содержание
Что это и как работает
Вот есть у нас некий Вася, который решил купить машину. Такую, как в рекламе — быструю, мощную, красивую! Только стоит она как хвост самолета, у Васи таких денег нет.
Конечно, Вася может подкопить несколько лет, а потом уже покупать машину. Но ведь хочется здесь и сейчас! Да и средство передвижения нужно…
А еще Вася не умеет копить — получил зарплату, закупился основным, оплатил жилье, всё! Остальное можно потратить. Для таких людей есть банки, куда можно прийти и взять деньги в кредит.
Конечно, потом вы будете переплачивать, возвращая их назад. Проценты-то конские. Но зато уже сейчас можете позволить купить себе что-то дорогое.
Вася подумал, прикинул и сказал:
— Да, хочу именно так! 100 рублей с зарплаты платить в банк могу, а откладывать — нет. Потрачу.
Поэтому Вася идет в банк и говорит:
— Я Василий Иванов, хочу автокредит на 1000р.
У Кати есть специальная программа для проверки данных по клиентам. Эта программа может быть как web, так и desktop:
Катя вбивает в программу «Василий Иванов» и получает информацию по клиенту — есть ли он в черных списках? Была ли кредитная история раньше? И так далее. Но что происходит в потрохах приложения?
Катя ввела данные на клиенте. Но когда она нажала «проверить», клиент отправил запрос на сервер:
— Дай мне информацию по Васе Иванову!
Сервер отправил запрос в БД, базу данных:
— Select * from clients where fio = ‘Василий Иванов’. (Дай мне всю информацию по ФИО ‘Василий Иванов’)
— Вот тебе все, что нашла.
Сервер вернул эту информацию клиенту:
А клиент уже отрисовал ее для Кати:
— Ага, кредитная история хорошая.
И делает предложение Васе:
— Пожалуйста, если хотите взять кредит, то мы готовы выделить 1000р на 12 лет под 80% годовых. Устроит?
— Да, меня всё устраивает, давайте скорее деньги, и я побежал за машиной!
Все счастливы, все довольны.
Катя даже не догадывается, какой путь проделали данные в программе, когда она вбила туда ФИО своего клиента. Но мы с вами должны узнать, что же это за путь такой? И к чему все эти сложности? Почему именно такая структура? Почему есть клиент, почему есть сервер?
Зачем нужен клиент
Тут все просто — с клиентом работает пользователь. Он нужен, чтобы превратить байтики программного кода в красивую и понятную картинку. Пользователь — не программист, он не понимает язык программирования или sql. Он понимает формочки и кнопочки. Их в клиенте и рисуем.
Зачем нужен сервер
Клиентов может быть много. В примере с банком у нас может быть по 10 отделений в 10 городах России, а в каждом отделении по 10 операционисток. Тысяча Катек, и у каждой отдельный компьютер.
А мы ведь хотим, чтобы приложение работало быстро. Чтобы оно не тупило и не зависало, нервируя операциониста и заставляя клиента ждать. Значит, машина нужна мощная. Но если делать мощным каждый компьютер операциониста, денег придется вложить очень много!
Поэтому мы выносим всю основную логику на сервер. И вот его уже делаем мощным! А клиентские машины могут быть дешевыми, потому что на них остается лишь логика в стиле «запросить информацию и красиво отрисовать».
Нет дублирования кода
Если бы у нас были только клиентские машины, на каждой из них хранился бы одинаковый код по обработке логики, лежала вся база данных, все справочники террористов и прочая. Но так как сервер и БД вынесены в отдельные звенья, с клиентской машины освобождается куча места… И кода.
Не надо дублировать код, ведь вся основная логика вынесена на более мощный сервер.
На сервере и в базе хранится информация, недоступная простому операционисту. Это:
Есть операционисты, готовые за денюшку слить информацию о клиентах. Есть нечистые на руку люди, готовые невзначай заглянуть через плечо. А, может, клиент сам такой человек. Представляете, отпихивает Вася хрупкую Катю, садится за ее компьютер, и переводит себе на счет миллионы, пока его не повяжет охрана.
Зачем нужна база
При чем же тут БД? Вот у нас есть наш сервер, пусть он и хранит всю информацию. Бывает и так, иногда база просто не нужна и у нас остается двузвенная архитектура клиент-сервер.
В таком случае все данных сервер хранит в памяти. Вот только если сервер упадет, или просто перезагрузится — вся информация будет потеряна. Все, что было в памяти, стирается при выключении системы.
БД (база данных) — отдельный программный продукт, который позволяет:
Да, базы может не быть. Но когда она есть, мы уверены в сохранности данных и легко можем по ним поискать.
Плюсы архитектуры
Резюмируем плюсы архитектуры:
Минусы архитектуры
Упало одно звено — все отдыхают
Если упал сервер или отвалилась база, то есть испортилось 1 звено — всё, все в ступоре, все отдыхают. Сотни, тысячи, да хоть миллионы клиентов если есть — никто не может работать. Все операционистки грустно смотрят на окно «Простите, что-то пошло не так» и разводят руками перед клиентом.
Именно поэтому в бизнес-критичном ПО архитектуру усложняют и даже дублируют. Банк с тысячами операционистов не может позволить себе простой. Поэтому они используют кластер серверов — один упал, остальные работают.
Как в таком случае клиент понимает, куда ему отправлять запрос?
Перед серверами ставят балансировщик, и клиент шлет запрос туда. Сколько бы серверов не поставили в кластер, клиенту это не интересно. У него есть один URL — адрес балансировщика.
И вот с клиента поступает запрос:
— Дай мне всю информацию по Васе Иванову.
— Ребята, новый запрос! Кто меньше загружен?
— У меня 5 запросов в очереди стоит.
Балансировщик отправляет запрос второму серверу.
Такая схема используется для высоконагруженного приложения — когда запросов поступает так много, что один сервер с ними просто не справляется.
Facebook, amazon, google — туда заходят миллионы пользователей. Один сервер с ними не справится. Поэтому ставят кластер, а балансировщик делит между ними нагрузку. И в таком случае в кластере может быть не 2 сервера, а 10, 15, сколько нужно, столько и ставим.
При этом мы можем точно также балансировать базу данных. У нас может быть несколько копий баз данных на самых разных машинах, и балансировщик отправляет запросы то к одной, то ко второй.
Такая схема называется горячий резерв — когда у нас есть несколько серверов, работающих в параллель, и балансировщик распределяет нагрузку между ними.
При этом может быть и схема холодного резерва — когда у нас второй сервер является резервной копией «на всякий случай». Все запросы идут на первый сервер, второй отдыхает.
Но если с первым сервером что-то случится и он помрет, балансировщик перенаправит нагрузку на второй сервер:
В это время у администраторов будет время разобраться с проблемой на сервере 1.
Схема холодного резерва используется тогда, когда один сервер способен выдержать нагрузку и выдавать хорошую скорость работы. Но приложение при этом бизнес-критичное и простой неприемлем.
Простой может быть не только потому, что случилось что-то плохое. Есть еще штатное обновление приложения. Обе схемы резервирования позволяют обновляться безболезненно. Если в кластере два сервера, обновление будет выглядеть так:
Таким образом, схемы резервирования помогают нам устранить проблему «упало 1 звено — все отдыхают». Клиент никогда не узнает, что один или несколько серверов в кластере сдохли, у него всё как работало, так и работает.
Высокая стоимость оборудования
Сервера стоят дорого. Туда нельзя поставить обычный SSD как для домашнего компьютера. Почему? Потому что к железу для серверов совсем другие требования по надежности + есть поддержка специфичных функций:
— у HDD это специальная микропрограмма контроллера, которая оптимизирована для работы диска в RAID, дома это не нужно.
— у SSD это наличие группы конденсаторов, которые хранят энергию на случай отключения питания, чтобы хватило времени скинуть из DDR кэша данные в энергонезависимую память и данные не побились.
SSD — быстро работающий диск, HDD — обычный. RAID — когда мы N дисков вместе соединили, а DDR кэш — это оперативная память
Плюс у серверных решений гарантия обычно гораздо дольше: 5 лет, а не год.
По цене отличаются в 2 раза. Например, SSD:
Вроде не сильно отличается, да? Но смысл в том, что для дома 1 тб хватает за глаза — и фоточки все влезут, и кино, и куча приложений… А для базы данных иногда и 10 тб будет мало. А если делать кластер, то умножаем стоимость на 2, если не больше. Поэтому и разница в цене кажется огромная, но при пересчете на гигабайт небольшая выходит.
Не забывайте, что дома вам просто надо свои фоточки держать, да и те обычно в облаке. А на сервере бизнес-критичный функционал, который жрет дофига ресурсов и который надо дублировать на случай «вдруг первый сдохнет».
Нужно нанять сисадмина ツ
Нам нужно нанять сисадмина, который будет следить за всеми нашеми серверами приложения и БД. Добавляем его зарплату к стоимости оборудования!
Что тестировать
Чтобы понимать, что тестировать, надо понимать, с чем имеет дело человек.
Пользователь работает с клиентом. Это может быть web или desktop приложение, не суть. Операционистке Кате дали рабочее место, показали какую программу запускать и как с ней работать. Она знать не знает о наличии серверов и БД, она работает только с клиентом.
Поэтому тестировщик в первую очередь проверяет клиент! Потому что сервер может работать идеально, вы можете даже написать тесты на уровне API и они все будут зелененькие, и кажется, что все зашибись! А пользователь загрузит отчет и увидит ошибку. Ой.
Сервер работает, на клиенте ошибка. И плевать на сотни «зеленых» автотестов. У пользователя все равно ошибка. И наша задача — посмотреть с его точки зрения.
Однако, если у вас есть доступ к серверу приложения и его базе данных — стоит проверять и их тоже! Так мы можем увидеть «будущий баг». Например:
— Ну, наверное, их и не заполняли.
А их заполняли! Просто сохранение криво сработало. Поэтому, если у нас только черный ящик, то нужно проверять, «а реально ли сохранились данные?». Сохранили? Откройте карточку в новом окне или вызовете информацию через API-метод.
Если доступ к базе есть — просто проверьте по ней, что все хорошо. Если есть доступ к серверным логам — проверьте их на наличие ошибок.
Помимо простых пользователей бывают злые люди, которые пытаются встрять в наше приложение и своровать деньги / данные. Они используют не клиент или сервер — туда у них доступа нет. Они пытаются перехватить данные в пути от клиента к серверу, или от сервера к БД.
Ну а раз нехорошие люди могут это сделать, то тестировщик тоже должен это уметь! Потому что тестировщик предоставляет информацию о нашем продукте.
Тестировщик изучает уязвимости и потом рассказывает команде:
— Ребята, вот я проверил, у нас есть такие-то и такие-то потенциальные дыры. Давайте подумаем, надо нам их как-то закрывать или нет.
То есть не факт, что исправлять проблему будут. Может, у вас некритичное приложение — данные не утекут, деньги вы не храните. Тогда и заморачиваться лишний раз никто не будет, потому что тестировать на защищенность — дорого, специалистов мало.
Но какие-то базовые проверки типа sql-иньекций или XSS-атак стоит изучить и проверить на своем приложении. Хотя бы чтобы понять их критичность. Ведь если атака сломает клиент — ну и пусть, сам себе буратино. А если атака положит сервер, это уже не очень хорошо. И надо хотя бы знать, от чего это бывает.
Итого
Клиент — та программа, с которой работает пользователь. Он знать не знает, это у него на компьютере программа целиком, или где-то за ней прячутся сервер с базой, а то и целый RAID. Он работает в браузере или с desktop-приложением. И всё, что ему нужно знать — это «куда тут тыкать».
Клиенту не нужно много памяти, места на диске и других ресурсов. Поэтому рабочие места относительно дешево стоят. А это именно то, что нам нужно, особенно если нужно закупить оборудование для тысяч операционисток банка.
Сервер — компьютер, на котором хранится само приложение. Весь код, вся логика, все дополнительные материалы и справочники. Например, справочник адресов ФИАС или справочник юр лиц ЕГРЮЛ — они тоже занимают место, как сами по себе, так и в памяти приложения.
Иногда говорят «сервер приложения» и «сервер БД». Это нормально, ведь фактически сервер — это просто машина, компьютер. А базу и сервер приложения обычно хранят на разных машинах, ради безопасности. В таком случае, если говорят «сервер приложения» — речь о втором звене нашей схемы.
Приложения бывают самые разные. Есть ресурсоемкие, им нужно много памяти и места на диске. Есть «легкие», которые можно развернуть даже на домашнем компьютере.
БД (база данных) — хранилище данных. Тут вы можете легко поискать информацию + уверены в том, что она сохранится, даже если в приложении что-то сломается. Подробнее о ней — в статье «Что такое База Данных (БД)»
Сколько места нужно под базу, зависит от количества данных. Есть огромные базы в банках, где и 1тб будет мало. А есть совсем небольшие, которые вы можете установить на своей машине. Например, XAMPP можно поставить. И врядли вы напихаете туда столько данных, что у вас не останется под них место.
Отдельной базы может не быть, тогда структура станет двузвенной: клиент-сервер. И все!
Схема условная, в реальной жизни у нас как минимум будет больше клиентов. А если приложение высоконагруженное, то будет несколько серверов и несколько баз данных:
PS — больше полезных статей ищите в моем блоге по метке «полезное». А полезные видео — на моем youtube-канале
Введение в сети клиент-сервер
Серверы и клиенты являются строительными блоками компьютерных сетей
Сеть клиент-сервер стала популярной много лет назад, поскольку персональные компьютеры стали альтернативой старым мейнфреймам компьютерам. Сеть клиент-сервер относится к компьютерной модели сети, в которой используются как клиентские аппаратные устройства, так и серверы, каждый из которых имеет определенные функции. Модель клиент-сервер может использоваться в Интернете, а также в локальных сетях (ЛВС). Примеры клиент-серверных систем в Интернете включают веб-браузеры и веб-серверы, FTP-клиенты и серверы, а также DNS.
Клиентское и серверное оборудование
Клиентские устройства – это обычно ПК с установленными сетевыми приложениями, которые запрашивают и получают информацию по сети. Кроме того, мобильные устройства функционируют как клиенты.
Серверы хранят файлы и базы данных, в том числе сложные приложения и веб-сайты. Серверы обычно имеют более мощные центральные процессоры, больше памяти и дисков больше, чем клиентские устройства.
Клиент-серверные приложения
Модель клиент-сервер организует сетевой трафик с использованием клиентского приложения и клиентских устройств. Сетевые клиенты отправляют сообщения на сервер для выполнения запросов. Серверы отвечают своим клиентам, реагируя на каждый запрос и возвращая результаты. Один сервер поддерживает множество клиентов, и несколько серверов могут быть объединены в сеть в пуле серверов для обработки возросших нагрузок по мере роста числа клиентов.
Клиентский компьютер и серверный компьютер, как правило, представляют собой два отдельных аппаратных блока, каждый из которых настроен для своего предназначения. Например, веб-клиент лучше всего работает с большим экраном, а веб-сервер вообще не нуждается в отображении и может быть расположен в любой точке мира. Однако в некоторых случаях данное устройство может функционировать как клиент и сервер для одного и того же приложения. Кроме того, устройство, которое является сервером для одного приложения, может одновременно действовать как клиент для других серверов для различных приложений.
Некоторые из самых популярных приложений в Интернете следуют модели клиент-сервер, включая электронную почту, FTP и веб-сервисы. Каждый из этих клиентов имеет пользовательский интерфейс – графический или текстовый – и клиентское приложение, которое позволяет пользователю подключаться к серверам. В случае электронной почты и FTP пользователи вводят имя компьютера (или иногда IP-адрес) в интерфейс для настройки соединений с сервером.
Локальные клиент-серверные сети
Клиент-сервер против одноранговых и других моделей
Модель сети клиент-сервер изначально была разработана для обеспечения доступа к приложениям баз данных для большого числа пользователей. По сравнению с моделью мэйнфрейма, клиент-серверная сеть обладает большей гибкостью, поскольку соединения могут быть установлены по требованию, а не фиксированы. Модель клиент-сервер также поддерживает модульные приложения, которые могут упростить создание программного обеспечения. В так называемых типах клиент-серверных систем двухуровневая и трехуровневая программные приложения разделены на модульные компоненты, и каждый компонент устанавливается на клиентах или серверах. специализированный для этой подсистемы.
Сеть клиент-сервер – это всего лишь один из подходов к управлению сетевыми приложениями. Первичная альтернатива клиент-серверной сети, одноранговая сеть, рассматривает все устройства как имеющие эквивалентные возможности, а не специализированные роли клиента или сервера. По сравнению с клиент-серверными сетями одноранговые сети предлагают некоторые преимущества, такие как большая гибкость в расширении сети для обслуживания большого количества клиентов. Клиент-серверные сети обычно предлагают преимущества по сравнению с одноранговыми сетями, например, возможность управлять приложениями и данными в одном централизованном месте.
Как видно из названия, главные «действующие лица»:
· клиент – компьютерное устройство, которое отсылает запросы серверу, касающиеся выполнения определенных задач или предоставления конкретной информации.
· сервер – компьютерное устройство, гораздо мощнее обычного ПК.
Система работает по следующему принципу:
1. Клиент отправляет запрос серверной машине.
2. Сервер принимает обращение с требованием выполнить определенное действие и выполняет поставленную задачу.
3. Программно-аппаратный комплекс отправляет клиенту результат выполненной работы, обработанного запроса.
Модель клиент-сервер предоставляет возможность разграничить поставленные задачи и работу над вычислениями между теми, кто заказывает услуги и теми, кто их поставляет.
Основные компоненты системы:
· клиент. Рабочая станция считается входной точкой конечного пользователя в данной системе. Отправляет запросы, получает ответы;
· сервер. Взаимодействует с многочисленными клиентами и решает поставленные ими задачи;
· сеть. Здесь происходит передача данных. Посредством сети можно соединить рабочие машины общими ресурсами;
· приложения. Могут обрабатывать информацию, организовывать физическое распределение данных между сервером и клиентом. Программным обеспечением оснащают серверные устройства для сбора данных, работы с ними и хранения. А также ПО устанавливают на компьютерной станции-клиенте.
О технологии клиент-сервер
Серверное устройство поддерживает многопользовательский режим и обеспечивает одновременно работу с несколькими клиентами. Конечно, машина не может решать в прямом смысле слова одновременно несколько поставленных задач, она выстраивает запросы в очередь по мере поступления, обрабатывает обращения и отправляет результаты работы. Запросы можно выстраивать в списке по приоритетности. Чем важнее запрос, тем быстрей его обрабатывают, даже, если он поступил позже.
Рядовые пользователи сети интернет даже не догадываются о том, как их запросы моментально обслуживаются, чтобы они читали новости, книги, тематические статьи, смотрели интересные видео и фильмы, ходили по форумам, «зависали» в социальных сетях, оплачивали счета, общались с друзьями, оформляли заказы на покупку товаров и т.д. Главное, что ответная реакция быстрая.
Именно технология клиент сервер предоставляет возможность реализовать вышеуказанные многочисленные поставленные задачи. Обычно клиент – это браузер конкретного пользователя. А серверами зачастую выступают:
· любые серверы http;
· наборы серверных машин (например, Denwer);
Обмен информацией между клиентом и сервером происходит благодаря сетевым протоколам в интернете. Каждой услуге соответствует определенный протокол, их предостаточно. Запросы, отсылаемые клиентом, классифицируют как http сообщения. Здесь четко указано, какие сведения нужно предоставить, в каком оформлении. Серверное устройство после анализа и обработки запроса, обычно отвечает html документом – дает свой http ответ.
Сообщение от клиента поступает с дополнительными данными, чтобы серверу было понятно, как с ним работать. Ответ машины также отправляется с кодами помимо полезных запрашиваемых данных, чтобы браузер оценил понятливость аппаратно-программного комплекса при обработке его запроса.
Смотря на каком уровне осуществляется взаимосвязь клиента с сервером, отсылаемые сообщения браузером упаковываются по-разному. Как будто они оборачиваются клиентом в несколько слоем обертки. После того, как послание поступило серверной станции, она приступает к разворачиванию всех этих слоев, проводит анализ информации и сбор данных.
Говоря больше о технологии клиент-сервер, следует уточнить, что браузер первый выходит на контакт и делает запрос серверной машине, которая лишь предоставляет услуги в ответ на сообщения и указывает, какие условия нужно при этом соблюдать. Разные компьютерные устройства используют, чтобы установить программное обеспечение клиента и серверного оборудования. Но есть случаи, когда они работали на одном ПК.
Когда на одном сайте одновременно находятся несколько посетителей, к серверу в один момент обращается много клиентов. Однако одномоментное поступление запросов ограничено мощностью и возможностями серверных устройств, а также характером отправляемых сообщений.
Архитектура клиент-сервер
Благодаря архитектуре клиент и сервер определены позиции взаимной связи между компьютерными машинами лишь в целом. Что же касается нюансов взаимодействия, они определены протоколами. Технология вполне прозрачно намекает на разделение в сети рабочих машин: серверы и клиенты. Рабочий контакт всегда инициирован клиентской машиной. Протокол же описывает, по каким правилам этот контакт установлен и действует.
Архитектура взаимодействия между клиентом и сервером подразделяется на два вида:
· двухзвенная. Сторонние ресурсы не задействованы. Одна машина обрабатывает поступившие сообщения. В этом случае сервер должен быть высокопроизводительным. Несмотря на эти жесткие требования, архитектура очень надежная. Первый уровень – клиент отправляет запрос. Второй уровень – сервером принимается сообщение, обрабатывается и отправляется ответ.
· многоуровневая. Речь идет о любой современной архитектуре СУБД. Принципиальное отличие и особенность: запросом клиента занимаются одновременно несколько серверных устройств. Операции перераспределяются, нагрузка на серверную машину снижена и оптимальная. Единственный минус: низкая надежность по сравнению с предыдущим вариантом.
Многоуровневая клиент-серверная архитектура
Обработкой данных занимаются несколько разных серверов. Благодаря такому подходу возможности серверов и клиентов используются более эффективно за счет разделения функций:
К тому же, систему можно точнее разделить на функциональные блоки для выполнения конкретной роли. Для этого между собой взаимодействуют разнообразные серверы приложений. К примеру, реально выделить сервер, необходимый для выполнения всего функционала по управлению персоналом. При этом реально сделать такую настройку, что пользователи смогут пользоваться только его общедоступным функционалом, а детали реализации серверной машины будут недоступны, так как с ней свяжут отдельную базу данных. Подобные системы легко адаптируются под веб, ведь легче организовать доступ пользователей к конкретному функционалу БД посредством html форм, чем ко всей БД.
На веб-технологию очень просто перевести многоуровневую систему. Заменяют клиентскую часть браузером спецтипа или универсального назначения. При этом дополняют веб-сервером и компактными программными модулями сервер приложений. Многоуровневая архитектура также использует менеджеры транзакций. Обмен информацией одновременно происходит между одной серверной машиной приложений и несколькими серверами БД.
· информация защищена и безопасно хранится. Так как серверная машина БД ведет базы данных, можно независимо от программ пользователя обрабатывать информацию в базе;
· повышенная стойкость к сбоям. Сохранена целостность информационных запросов, они доступны другим пользователям, если во время работы клиента случился сбой;
· масштабируемость. Архитектура адаптируется к увеличению количества пользователей. База данных также расширяется в объеме. Однако при этом не поставлена задача менять ПО. Система наращивает аппаратные средства, так происходит подстройка под меняющиеся факторы;
· повышенная защита данных от взлома и опасных атак;
· один пользователь меньше нагружает сеть, поэтому увеличивается ее пропускная способность. Можно удовлетворить запросы большего количества пользователей;
Преимущества и недостатки архитектуры клиент-сервер
Разделен код программы клиентского и серверного приложения. Это главное преимущество архитектуры. Выбрана локальная сеть. Поэтому плюсы следующие:
· к клиентским рабочим станциям выдвигают низкие запросы;
· преимущественно все вычислительные операции выполняются на серверах;
· реально повысить защиту локальной сети.
Но не все так гладко с клиент-серверной архитектурой, есть и недостатки:
· серверные машины стоят в разы дороже, чем клиентские рабочие станции;
· обслуживание серверов доверяют только квалифицированным и профессионально подготовленным специалистам;
· работа клиентских компьютерных устройств остановлена, если в локальной сети «полетело» серверное оборудование.
Важно понимать, что нет четкого разделения оборудования на клиентское и серверное. Просто архитектура к/с дает возможность перераспределить и оптимизировать загруженность и распределить функциональность между этими рабочими станциями.