) Здравствуйте! Я Александр Макаров, и вы можете меня знать по фреймворку «Yii» — я один из его разработчиков. У меня также есть full-time работа — и это уже не стартап — Stay.com, который занимается путешествиями.
Сегодня я буду рассказывать про горизонтальное масштабирование, но в очень-очень общих словах.
Что такое масштабирование, вообще? Это возможность увеличить производительность проекта за минимальное время путем добавления ресурсов.
Обычно масштабирование подразумевает не переписывание кода, а либо добавление серверов, либо наращивание ресурсов существующего. По этому типу выделяют вертикальное и горизонтальное масштабирование.
Вертикальное — это когда добавляют больше оперативки, дисков и т.д. на уже существующий сервер, а горизонтальное — это когда ставят больше серверов в дата-центры, и сервера там уже как-то взаимодействуют.
Самый классный вопрос, который задают, — а зачем оно надо, если у меня все и на одном сервере прекрасно работает? На самом-то деле, надо проверить, что будет. Т.е., сейчас оно работает, но что будет потом? Есть две замечательные утилиты — ab и siege, которые как бы нагоняют тучу пользователей конкурента, которые начинают долбить сервер, пытаются запросить странички, послать какие-то запросы. Вы должны указать, что им делать, а утилиты формируют такие вот отчеты:
Главные два параметра: n — количество запросов, которые надо сделать, с — количество одновременных запросов. Таким образом они проверяют конкурентность.
На выходе получаем RPS, т.е. количество запросов в секунду, которое способен обработать сервер, из чего станет понятно, сколько пользователей он может выдержать. Все, конечно, зависит от проекта, бывает по-разному, но обычно это требует внимания.
Есть еще один параметр — Response time — время ответа, за которое в среднем сервер отдал страничку. Оно бывает разное, но известно, что около 300 мс — это норма, а что выше — уже не очень хорошо, потому что эти 300 мс отрабатывает сервер, к этому прибавляются еще 300-600 мс, которые отрабатывает клиент, т.е. пока все загрузится — стили, картинки и остальное — тоже проходит время.
Бывает, что на самом деле пока и не надо заботиться о масштабировании — идем на сервер, обновляем PHP, получаем 40% прироста производительности и все круто. Далее настраиваем Opcache, тюним его. Opcache, кстати, тюнится так же, как и APC, скриптом, который можно найти в репозитории у Расмуса Лердорфа и который показывает хиты и мисы, где хиты — это сколько раз PHP пошел в кэш, а мисы — сколько раз он пошел в файловую систему доставать файлики. Если прогнать весь сайт, либо запустить туда какой-то краулер по ссылкам, либо вручную потыкать, то у нас будет статистика по этим хитам и мисам. Если хитов 100%, а мисов — 0%, значит, все нормально, а если есть мисы, то надо выделить больше памяти, чтобы весь наш код влез в Opcache. Это частая ошибка, которую допускают — вроде Opcache есть, но что-то не работает…
Еще часто начинают масштабировать, но не смотрят, вообще, из-за чего все работает медленно. Чаще всего лезем в базу, смотрим — индексов нет, ставим индексы — все сразу залетало, еще на 2 года хватит, красота!
Ну, еще надо включить кэш, заменить apache на nginx и php-fpm, чтобы сэкономить память. Будет все классно.
Все перечисленное достаточно просто и дает вам время. Время на то, что когда-то этого станет мало, и к этому уже сейчас надо готовиться.
Как, вообще, понять, в чем проблема? Либо у вас уже настал highload, а это не обязательно какое-то бешеное число запросов и т.д., это, когда у вас проект не справляется с нагрузкой, и тривиальными способами это уже не решается. Надо расти либо вширь, либо вверх. Надо что-то делать и, скорее всего, на это мало времени, что-то надо придумывать.
Первое правило — никогда ничего нельзя делать вслепую, т.е. нам нужен отличный мониторинг. Сначала мы выигрываем время на какой-то очевидной оптимизации типа включения кэша или кэширования Главной и т.п. Потом настраиваем мониторинг, он нам показывает, чего не хватает. И все это повторяется многократно – останавливать мониторинг и доработку никогда нельзя.
Что может показать мониторинг? Мы можем упереться в диск, т.е. в файловую систему, в память, в процессор, в сеть… И может быть такое, что, вроде бы, все более-менее, но какие-то ошибки валятся. Все это разрешается по-разному. Можно проблему, допустим, с диском решить добавлением нового диска в тот же сервер, а можно поставить второй сервер, который будет заниматься только файлами.
На что нужно обращать внимание прямо сейчас при мониторинге? Это:
- доступность, т.е. жив сервер, вообще, или нет;
- нехватка ресурсов диска, процессора и т.д.;
- ошибки.
Вот список замечательных инструментов, которые позволяют мониторить ресурсы и показывать результаты в очень удобном виде:
Этот доклад - расшифровка одного из лучших выступлений на обучающей конференции разработчиков высоконагруженных систем за 2015 год.Старьё! - скажите вы.
- Вечные ценности! - ответим мы. Добавить метки
Оптимальным решением проблемы информационного взаимодействия САПР на предприятии является внедрение базовой САПР предприятия, которая будет выступать связующим звеном, объединяющим разнородные результаты инженерного труда в единую открытую информационную систему.
Рассмотрим Solidworks как открытую информационную систему, проанализировав некоторые свойства открытой системы:
· Расширяемость;
· Масштабируемость;
· Интероперабельность;
· Способность к интеграция.
Расширяемость
Принцип расширяемости заключается в следующем: информационная система должна быть создана таким образом, чтобы можно было легко внести дополнения и изменения и тем самым не нарушить целостность системы.
Немаловажным при выборе САПР является вопрос расширяемости системы, а именно SolidWorks предлагает пользователям самый широкий выбор дополнений для программного комплекса. Для решения различных прикладных инженерных задач разработчики SolidWorks использовали дополнения MSC.visualNastran, Sigmund1D и EmbassyWorks. Выбор данных изменений был обусловлен двумя факторами. Во-первых, они позволяют решить поставленные задачи с минимальными затратами времени и средств, а во-вторых, эти изменения являются важными для пользователя, использующего SolidWorks, что исключает трудности с передачей геометрии, полностью сохраняет параметризацию и упрощает работу с данными комплексами и увеличивает функционал всей системы.
Например, для расчета напряжений и деформаций конструкций была использовано дополнение MSC.visualNastran. Оно позволяет проводить прочностные расчеты в упруго-линейной зоне с учетом малых деформаций. Его также можно использовать для определения собственных частот и форм колебаний; критических сил и форм потери устойчивости; проведения теплового анализа. Дополнение также включает модуль, позволяющий оптимизировать параметры конструкции при заданных ограничениях.
Масштабируемость
Масштабимруемость (англ. scalability)-свойство информационной системы, в электронике и информатике означает способность системы, сети или процесса справляться с увеличением рабочей нагрузки (увеличивать свою производительность).
Разработчики SolidWorks большое внимание уделяют работе с комплексными сборками, количество компонентов которых может составлять десятки и сотни тысяч единиц. Безусловно, для работы с такими моделями требуется использовать специальные методики управления отдельными деталями и узлами сборки, рационально распоряжаться ресурсами процессора и оперативной памяти. Для этого в SolidWorks существует специальный режим, который так и называется "Режим работы с большими сборками". Этот режим позволяет оптимально распределить программные и аппаратные ресурсы, экономя, таким образом, время загрузки и перестроения сборки.
3.2KПредставим, что мы сделали сайт. Процесс был увлекательным и очень приятно наблюдать, как увеличивается число посетителей.
Но в какой-то момент, траффик начинает расти очень медленно, кто-то опубликовал ссылку на ваше приложение в Reddit или Hacker News , что-то случилось с исходниками проекта на GitHub и вообще, все стало как будто против вас.
Ко всему прочему, ваш сервер упал и не выдерживает постоянно растущей нагрузки. Вместо приобретения новых клиентов и/или постоянных посетителей, вы остались у разбитого корыта и, к тому же, с пустой страничкой.
Все ваши усилия по возобновлению работы безрезультатны – даже после перезагрузки, сервер не может справиться с потоком посетителей. Вы теряете трафик!
Никто не может предвидеть проблемы с трафиком. Очень немногие занимаются долгосрочным планированием, когда работают над потенциально высокодоходным проектом, чтобы уложиться в фиксированные сроки.
Как же тогда избежать всех этих проблем? Для этого нужно решить два вопроса: оптимизация и масштабирование .
Оптимизация
Первым делом, стоит провести обновление до последней версии PHP (текущая версия 5.5, использует OpCache ), проиндексировать базу данных и закэшировать статический контент (редко изменяющиеся страницы вроде About , FAQ и так далее).
Оптимизация затрагивает не только кэширование статических ресурсов. Также, есть возможность установить дополнительный не-Apache-сервер (например, Nginx ), специально предназначенный для обработки статического контента.
Идея заключается в следующем: вы помещаете Nginx перед вашим Apache-сервером (Ngiz будет frontend -сервером, а Apache — backend ), и поручаете ему, перехват запросов на статические ресурсы (т.е. *.jpg , *.png , *.mp4 , *.html …) и их обслуживание БЕЗ ОТПРАВЛЕНИЯ запроса на Apache.
Такая схема называется reverse proxy (её часто упоминают вместе с техникой балансировки нагрузки, о которой рассказано ниже).
Масштабирование
Существует два типа масштабирования – горизонтальное и вертикальное .
Мы говорим, что сайт масштабируем, когда он может выдерживать увеличение нагрузки без необходимости внесения изменений в программное обеспечение.
Вертикальное масштабирование
Представьте, что у вас имеется веб-сервер, обслуживающий веб-приложение. Этот сервер имеет следующие характеристики 4GB RAM , i5 CPU и 1TB HDD .
Он хорошо выполняет возложенные на него задачи, но чтобы лучше справляться с нарастающим трафиком, вы решаете заменить 4GB RAM на 16GB, устанавливаете новый i7 CPU и добавляете гибридный носитель PCIe SSD/HDD .
Сервер теперь стал более мощным и может выдерживать увеличенные нагрузки. Именно это и называется вертикальным масштабированием или «масштабированием вглубь » – вы улучшаете характеристики машины, чтобы сделать её более мощной.
Это хорошо проиллюстрировано на изображении ниже:
Горизонтальное масштабирование
С другой стороны, мы имеем возможность произвести горизонтальное масштабирование. В примере, приведенном выше, стоимость обновления железа едва ли будет меньше стоимости первоначальных затрат на приобретение серверного компьютера.
Это очень финансово затратно и часто не дает того эффекта, который мы ожидаем – большинство проблем масштабирования относятся к параллельному выполнению задач.
Если количества ядер процессора недостаточно для выполнения имеющихся потоков, то не имеет значения, насколько мощный установлен CPU – сервер все равно будет работать медленно, и заставит посетителей ждать.
Горизонтальное масштабирование подразумевает построение кластеров из машин (часто достаточно маломощных), связанных вместе для обслуживания веб-сайта.
В данном случае, используется балансировщик нагрузки (load balancer ) – машина или программа, которая занимается тем, что определяет, какому кластеру следует отправить очередной поступивший запрос.
А машины в кластере автоматически разделяют задачу между собой. В этом случае, пропускная способность вашего сайта возрастает на порядок по сравнению с вертикальным масштабированием. Это также известно как «масштабирование вширь ».
Есть два типа балансировщиков нагрузки – аппаратные и программные . Программный балансировщик устанавливается на обычную машину и принимает весь входящий трафик, перенаправляя его в соответствующий обработчик. В качестве программного балансировщика нагрузки, может выступить, например, Nginx .
Он принимает запросы на статические файлы и самостоятельно их обслуживает, не обременяя этим Apache. Другим популярным программным обеспечением для программной балансировки является Squid , который я использую в своей компании. Он предоставляет полный контроль над всеми возможными вопросами посредством очень дружественного интерфейса.
Аппаратные балансировщики представляет собой отдельную специальную машину, которая выполняет исключительно задачу балансировки и на которой, как правило, не установленного другого программного обеспечения. Наиболее популярные модели разработаны для обработки огромного количества трафика.
При горизонтальном масштабировании происходит следующее:
Заметьте, что два описанных способа масштабирования не являются взаимоисключающими – вы можете улучшать аппаратные характеристики машин (также называемых нодами — node ), используемых в масштабированной вширь кластерной системе.
В данной статье мы сфокусируемся на горизонтальном масштабировании, так как в большинстве случаев оно предпочтительнее (дешевле и эффективнее), хотя его и труднее реализовать с технической точки зрения.
Сложности с разделением данных
Имеется несколько скользких моментов, возникающих при масштабировании PHP-приложений. Узким местом здесь является база данных (мы еще поговорим об этом во второй части данного цикла).
Также, проблемы возникают с управлением данными сессий, так как залогинившись на одной машине, вы окажетесь неавторизованным, если балансировщик при следующем вашем запросе перебросит вас на другой компьютер. Есть несколько способов решения данной проблемы – можно передавать локальные данные между машинами, либо использовать постоянный балансировщик нагрузки.
Постоянный балансировщик нагрузки
Постоянный балансировщик нагрузки запоминает, где обрабатывался предыдущий запрос того или иного клиента и, при следующем запросе, отправляет запрос туда же.
Например, если я посещал наш сайт и залогинился там, то балансировщик нагрузки перенаправляет меня, скажем, на Server1 , запоминает меня там, и при следующем клике, я вновь буду перенаправлен на Server1 . Все это происходит для меня совершенно прозрачно.
Но что, если Server1 упал? Естественно, все данные сессии будут утеряны, а мне придется логиниться заново уже на новом сервере. Это очень неприятно для пользователя. Более того, это лишняя нагрузка на балансировщик нагрузки: ему нужно будет не только перенаправить тысячи людей на другие сервера, но и запомнить, куда он их перенаправил.
Это становится еще одним узким местом. А что, если единственный балансировщик нагрузки сам выйдет из строя и вся информации о расположении клиентов на серверах будет утеряна? Кто будет управлять балансировкой? Замысловатая ситуация, не правда ли?
Разделение локальных данных
Разделение данных о сессиях внутри кластера определенно кажется неплохим решением, но требует изменений в архитектуре приложения, хотя это того стоит, потому что узкое место становится широким. Падение одного сервера перестает фатально влиять на всю систему.
Известно, что данные сессии хранятся в суперглобальном PHP-массиве $_SESSION . Также, ни для кого не секрет, что этот массив $_SESSION хранится на жестком диске.
Соответственно, так как диск принадлежит той или иной машине, то другие к нему доступа не имеют. Тогда как же организовать к нему общий доступ для нескольких компьютеров?
Замечу, что обработчики сессий в PHP могут быть переопределены – вы можете определить свой собственный класс/функцию для управления сессиями.
Использование базы данных
Используя собственный обработчик сессий, мы можем быть уверены, что вся информация о сессиях хранится в базе данных. База данных должна находиться на отдельном сервере (или в собственном кластере). В таком случае, равномерно нагруженные сервера, будут заниматься только обработкой бизнес-логики.
Хотя данный подход работает достаточно хорошо, в случае большого трафика, база данных становится не просто уязвимым местом (потеряв её, вы потеряете все), к ней будет много обращений из-за необходимости записывать и считывать данные сессий.
Это становится очередным узким местом в нашей системе. В этом случае, можно применить масштабирование вширь, что проблематично при использовании традиционных баз данных типа MySQL , Postgre и тому подобных (эта проблема будет раскрыта во второй части цикла).
Использование общей файловой системы
Можно настроить сетевую файловую систему, к которой будут обращаться все серверы, и работать с данными сессий. Так делать не стоит. Это совершенно неэффективный подход, при котором велика вероятность потери данных, к тому же, все это работает очень медленно.
Это еще одна потенциальная опасность, даже более опасная, чем в случае с базой данных, описанном выше. Активация общей файловой системы очень проста: смените значение session.save_path в файле php.ini , но категорически рекомендуется использовать другой способ.
Если вы все-таки хотите реализовать вариант с общей файловой системой, то есть гораздо более лучшее решение — GlusterFS .
Memcached
Вы можете использовать memcached для хранения данных сессий в оперативной памяти. Это очень небезопасный способ, так как данные сессий будут перезаписаны, как только закончится свободное дисковое пространство.
Какое-либо постоянство отсутствует – данные о входе будут храниться до тех пор, пока memcached -сервер запущен и имеется свободное пространство для хранения этих данных.
Вы можете быть удивлены – разве оперативная память не отдельна для каждой машины? Как применить данный способ к кластеру? Memcached имеет возможность виртуально объединять всю доступную RAM нескольких машин в единое хранилище:
Чем больше машин у вас в наличии, тем больше будет размер созданного общего хранилища. Вам не нужно вручную распределять память внутри хранилища, однако вы можете управлять этим процессом, указывая, какое количество памяти можно выделить от каждой машины для создания общего пространства.
Таким образом, необходимое количество памяти остается в распоряжении компьютеров для собственных нужд. Остальная же часть используется для хранения данных сессий всего кластера.
В кэш, помимо сессий могут попадать и любые другие данные по вашему желанию, главное чтобы хватило свободного места. Memcached это прекрасное решение, которое получило широкое распространение.
Использовать этот способ в PHP-приложениях очень легко: нужно изменить значение в файле php.ini :
session.save_handler = memcache session.save_path = "tcp://path.to.memcached.server:port"
Redis Cluster
Redis это не SQL хранилище данных, расположенное в оперативной памяти, подобно Memcached , однако оно имеет постоянство и поддерживает более сложные типы данных, чем просто строки PHP-массива в форме пар «key => value ».
Это решение не имеет поддержки кластеров, поэтому реализация его в горизонтальной системе масштабирования не так проста, как может показаться на первый взгляд, но вполне выполняема. На самом деле, альфа-версия кластерной версии уже вышла и можно её использовать.
Если сравнивать Redis с решениями вроде Memcached , то он представляет собой нечто среднее между обычной базой данных и Memcached .
Другие решения:
- ZSCM от Zend – хорошая альтернатива, но требует установки Zend Server на каждый нод в кластере;
- Прочие не SQL хранилища и системы кэширования также вполне работоспособны – ознакомьтесь с Scache , Cassandra или Couchbase , все они работают быстро и надежно.
Заключение
Как вы могли понять из написанного выше, горизонтальное масштабирование PHP-приложений это не пикник на выходных.
Вертикальное масштабирование — scaling up — увеличение количества доступных для ПО ресурсов за счет увеличения мощности применяемых с серверов.
— scaling out — увеличение количества нод, объединенных в кластер серверов при нехватке CPU, памяти или дискового пространства.
И то и другое является инфраструктурными решениями, которые в разных ситуациях требуются когда веб проект растет.
Вертикальное и горизонтальное масштабирование, scaling для web
Для примера можно рассмотреть сервера баз данных. Для больших приложений это всегда самый нагруженный компонент системы.
Возможности для масштабирования для серверов баз данных определяются применяемыми программными решениями: чаще всего это реляционные базы данных (MySQL, Postgresql) или NoSQL ( , Cassandra и др).
Горизонтальное масштабирование для серверов баз данных при больших нагрузках значительно дешевле
Веб-проект обычно начинают на одном сервере, ресурсы которого при росте заканчиваются. В такой ситуации возможны 2 варианта:
- перенести сайт на более мощный сервер
- добавить еще один сервер небольшой мощности с объединить машины в кластер
MySQL является самой популярной RDBMS и, как и любая из них, требует для работы под нагрузкой много серверных ресурсов. Масштабирование возможно, в основном, вверх. Есть шардинг (для его настройки требуется вносить изменения в код) и , которая может быть сложной в поддержке.
Вертикальное масштабирование
NoSQL масштабируется легко и второй вариант с, например, MongoDB будет значительно выгоднее материально, при этом не потребует трудозатратных настроек и поддержки получившегося решения. Шардинг осуществляется автоматически.
Таким образом с MySQL нужен будет сервер с большим количеством CPU и оперативной памяти, такие сервера имеют значительную стоимость.
Горизонтальное масштабирование
С MongoDB можно добавить еще один средний сервер
и полученное решение будет стабильно работать давая дополнительно отказоустойчивость.
Scale-out или является закономерным этапом развития инфраструктуры. Любой сервер имеет ограничения и когда они достигнуты или когда стоимость более мощного сервера оказывается неоправданно высокой добавляются новые машины. Нагрузка распределяется между ними. Также это дает отказоустойчивость.
Добавлять средние сервера и настраивать кластеры нужно начинать когда возможности для увеличения ресурсов одной машины исчерпаны или когда приобретение сервера мощнее оказывается невыгодно
Приведенный пример с реляционными базами данных и NoSQL является ситуацией, которая имеет место чаще всего. Масштабируются также фронтэнд и бэкенд сервера.
Читайте про и балансер
Под масштабируемостью корпоративных систем подразумевается возможность наращивания их мощности путем подключения новых технических и программных средств без дополнительной доработки последних. Этот момент важен при использовании современных компьютерных и сетевых технологий. Можно привести пример распределенной обработки данных в центральном банке и его филиалах.
Масштабируемость достигается на различных уровнях: а) Техническом; б) Системном; в) Сетевом; г) СУБД; д) Прикладном. Для ОС масштабируемость означает, что ОС не привязана к однопроцессорной архитектуре процессора. В случае усложнения стоящих перед пользователем задач и расширения предъявляемых к компьютерной сети требований, ОС должна обеспечивать возможность добавления более мощных и производительных серверов и рабочих станций в корпоративной сети. Можно рассматривать масштабируемость технических средств, программных средств, масштабируемость системы в целом. В основе масштабируемости лежат такие технологии как: а) Международные стандарты; б) Сетевые и телекоммуникационные технологии; в) Операционные системы; г) Технология клиент/сервер и ряд других средств.
Конец работы -
Эта тема принадлежит разделу:
Компьютерные информационные технологии в управлении. Классификация систем управления
Цель КИС подготовка к использованию современных информационных технологий в рамках КИС как инструмента для решения научных и практических задач в.. Понятие информационной технологии Корпоративные информационные..
Если Вам нужно дополнительный материал на эту тему, или Вы не нашли то, что искали, рекомендуем воспользоваться поиском по нашей базе работ:
Что будем делать с полученным материалом:
Если этот материал оказался полезным ля Вас, Вы можете сохранить его на свою страничку в социальных сетях:
| Твитнуть |
Все темы данного раздела:
Понятие информационной технологии. Корпоративные информационные технологии
Технология – сис-ма взаимосвязанных способов обработки материалов и приемов изготовления продукции в производственном процессе. Информационные технологии – система взаимосвязанных мет
Технология обработки информации. Понятие совместимости, открытости и модульности
Информация – совокупность фактов, явлений, событий, представляющих интерес, подлежащих регистрации и обработке. Это подразумевает наличие двух моментов: источник и приемник (потребитель) информации
Виды обеспечения информационных систем
Виды обеспечения АСОЭИ: а) Технические; б)Математические; в)Лингвистические; г)Программные. Информационное обеспечение – система классификации и кодирования информации, технологическая схема обрабо
Архитектура корпоративной информационной системы
Архитектура КИС состоит из нескольких уровней: а)Информационно-логический уровень–представляет собой совокупность потоков данных и центров (узлов) возникновения, потребления
Требования к корпоративным информационным системам
Процессы активного совершенствования технологий обработки информации являются следствием того, что к современным информационным системам (КИС) все чаще предъявляются следующие требования: а) структ
Неоднородность корпоративных информационных систем. Решения проблем неоднородности в корпоративных информационных системах
Важнейшую роль играют вопросы преодоления проблем неоднородности корпоративных систем и обеспечения совместимости компонент, входящих в ее состав. Неоднородность в вычислительных системах может про
Международные стандарты в области компьютерных информационных технологий
В настоящее время всемирное распространение получил комплекс стандартов на систему качества предприятия, разработанный ISO (International Standards Organization), точнее, техническим комитетом ISO/
Информационные модели объекта управления
Современное предприятие можно рассматривать как эффективный информационный центр, источниками информации которого являются внешняя и внутренняя деловая среда. Внешняя деловая среда –
Информационное обеспечение корпоративных информационных систем
Информационное обеспечение – система классификации и кодирования информации, технологическая схема обработки данных, нормативно-справочная информация, система документооборота и т.д. Информационное
Политика формирования информационных ресурсов как единого информационного пространства
Для обеспечения взаимодействия информационных ресурсов различного уровня необходимы: а) Использование современных информационных технологий; б) Современная транспортная информационная среда; в) Еди
Преимущества использования вычислительных систем
В результате использования многомашинных и многопроцессорных ВС оказывается возможным достичь следующих преимуществ:1) Повышение уровня производительности и получения быстродействи
Средства коммуникационной техники и средств связи
Средства коммуникационной техники обеспечивают одну из основных функций управленческой деятельности - передачу информации в рамках системы управления и обмен данными с внешней средой, предполагают
Операционные системы (ОС). Технологии ОС
Среди системных программ особое место занимает операционная система (ОС). Под операционной системой (ОС) (Operating System)понимают комплекс программ, осуществляющих управле
OS Unix и структурные решения в корпоративных информационных системах. Понятие мобильности
Начало разработок ОС Unix было положено фирмой Bell Laboratories в 1968 г. Была предложена многопользовательская 32-х разрядная ОС Unix для Main Frame. В 1976 г. компания AT&T (куда входила и B
Понятие компьютерных сетей и их характеристика
Компьютерная сеть – это комплекс территориально рассредоточенных ЭВМ, связанных между собой каналами передачи данных целях эффективного использования вычислительных ресурсов. Целесообразност
Состав компьютерных сетей
В состав компьютерных сетей входят технические, программные и информационные средства. То есть компьютерную сеть можно рассматривать как систему с распределенными по территории аппаратурными, прогр
Архитектура компьютерных сетей
В общем случае архитектуру компьютерных сетей можно рассматривать с двух точек зрения – это физическая организация компьютерной сети (топология сети) и организация сети на логическом уров
Компьютерные сети с выделенным сервером и их характеристика
Клиент-сервер - сетевая архитектура, в которой устройства являются либо клиентами, либо серверами. Клиентом является запрашивающая машина (обычно ПК), сервером- машина, которая отвеча
Структура глобальных компьютерных сетей
Глобальные сети (WAN, Wide Area Networks) это системы с широкополосными каналами и позволяют организовать взаимодействие между компьютерами на больших расстояниях. В идеале глобальная компьютерная
Масштабируемость компьютерных сетей
Масштабируемость – возможность наращивания ресурсов сети и абонентов. В компьютерных сетях с выделенным сервером, рабочие станции подключаются к выделенным серверам, а серверы, в свою очередь, груп
Протоколы Internet
Протокол в данном случае - это, образно говоря, «язык», используемый компьютерами для обмена данными при работе в сети. Чтобы различные компьютеры сети могли взаимодействовать, они должны «разговар
Адресация Internet
Интернет- всемирная система объединённых компьютерных сетей, построенная на использовании протокола IP и маршрутизации пакетов данных. Интернет образует глобальное информационное пространство, служ
