AIT 600-test

8/7/2019 AIT 600-test

1/24

Chapter 8

Performance and Scalability

Moores Law

Processor power increases by a factor of 2 every 19 months

Is this true?

How long will it continue if so?

The Un-Slippery Slope

Hardware Architecture Gap

The gap between what the processor could do and what it actually does do

The processor is faster than the memory and every now and then it must

wait

Figure 8-1


If reference is not in cache, it must fetch it from main memory

Doesnt seem like a big deal, right?


If space is needed in cache, then system must write cache to main memory before

fetching new data, causing a wait time for processor


If another processor is writing to memory first, then it may cause more delay

If another I/O is being done, there may be a delay

The wait time adds up and can create problems or time out, but most importantly wasted

cycles!

Hardware Architecture can have an impact on performance

Unisys CMP hardware

8/7/2019 AIT 600-test

2/24

Cross-bar memory interconnects

Third-level cache shared by processors

Separate I/O processors

There are 3 ways to improve performance:

1) Faster Processor

2) Improve Hardware Architecture

3) Push the application leftward, down the slope

How to push the application down the slope:

Reduce active memory footprint

Reduce the number of task switches

Reduce lock contentions

Reduce the number of I/Os

Reduce the number of network messages sent or received

Reduce the number of memory overlays

Reducing the active memory footprint

The amount of memory used for the main path processing

If the amount of memory needed for the application is more than what is available

in cache, the cache memory will continually be recycled

Reduce the number of task switches

Saving data values to main memory from cache and reloading a new set of values

Reusing data values in cache by two separate tasks may be rare

Reduce lock contention

Two processes attempting to use the same piece of data at the same time

Only one process can hold the lock on a piece of data at a time

8/7/2019 AIT 600-test

3/24

8/7/2019 AIT 600-test

4/24

The operating system, networking and database software all need to use memory

Use a transaction monitor to assist in sharing programs and resources among all

of the connected terminals

Two-Phase Commit

When you update two or more databases on different systems, there are additional

network messages and disk writes

Figure 8-6

Potential issues with the Two-Phase Commit

Source of delays exist when sub-transactions are initiated and a log is written on

subsystem

Locks can be held longer and potential timeouts can occur or lock contentions

Message Queuing Issues

You must set a schedule to empty the queue or start other systems to keep it

efficient

Another method would be to pass the messages to the transaction monitor to

process the messages, which would start the necessary services

Remote Database Access

Inefficient for real-time transactions

Every database call becomes a network message, or several messages

These messages increase network overhead

Using Transaction Servers Solve the Problem

Use store procedures to call the set of commands to run

Figure 8-7

Batch

3 Basic Reasons for Batch

1) Support cyclical business processes

8/7/2019 AIT 600-test

5/24

2) Support housekeeping tasks

3) Optimization

Perform some task prior to update

Updates are not done until batch is run

Batch Problems

Ran at night

Interferes with other updates

International business requires 24/7 uptime

Load Balancing

Figure 8-7

4 Tiers

Web Browsers

Web Servers

Transaction Servers

Database Servers

Load Balancing

Any number of Web Servers

Any number of Transaction Servers

All working on the same application

Any number of database servers

Load Balancing Web Servers

This requires special network router that allows the external connections to

connect at 1 point (IP/Web address)

The network router then spreads the connections among the web servers

8/7/2019 AIT 600-test

6/24

Also must ensure the data in all of the web servers is the same

Using the dual-active approach solves it

Put all state in the back-end

Business Intelligence Systems

Includes these types of systems:

Data Access

Data Marts

Data Warehouse

Decision Support

All need to handle Ad Hoc Queries and Data Replication

Ad Hoc Queries

I/O Intensive!

Causes:

Checking each record against the search criteria

Moving data to the output message

Sorting

Parsing the query, building a processing plan, and optimizing the plan

Managing temporary data

Doing arithmetic calculations, checking for nulls

And much, much more

Ad Hoc Queries

Large queries will need large amounts of memory

They will clear memory of other items not related

Large queries will dominate the I/O

8/7/2019 AIT 600-test

7/24

Data Replication

Take a copy of the database

Keep database up-to-date by applying the changes

Take changes from the logs

Do not commit failed processes

Is network intensive

Use less larger messages instead of many smaller ones

Data Replication

Delay usually occurs at system load time

Ways to handle the load:

Allow back-up to get behind during work hours and catch up overnight

Sort data before inserting into table

Use software to help manage the load

Backups and Recovery

The more users, the more important not to have a failure

The larger the database, the more likely of hardware failure

Theres more hardware that can fail

The more transactions, the bigger the log file

Larger the log file, the longer the reconstruction

The larger the database, the longer to backup

Backup copies should be made more frequently for large databases, so less to

reconstruct

Backups and Recovery

The bigger the database:

8/7/2019 AIT 600-test

8/24

The more there is to manage

The longer tasks will take

The bigger the files

The more space needed

The more people to please J

Figure 8-8

Web Services: Transmission Times

What can affect transmission times?

Packet loss

Distance to travel

Physical transmission medium

Bandwidth max speed

Network congestion

Condition of network infrastructure

Distributed System Performance Measurement

Unfortunately this is almost impossible

You can measure at single nodes

You can get an estimate of the overall performance but no real measurement

Chapter 9 Systems Management

5 Categories of Systems Management

1. Administration

2. Operation

8/7/2019 AIT 600-test

9/24

3. Fault tracking and resolution

4. Performance management and accounting

5. Security (discussed next week)

1. Administration

All aspects of managing the configuration of a system

Hardware additions/changes/ removals/updates

Software additions/changes/ removals/updates

User access to Network

2. Operation

Keeping the system running

Manage the work flowing through the system

Backups

Detecting faults

Starting and stopping transaction-processing applications

Running batch jobs

User maintenance for applications

3. Fault Tracking and Resolution

Faults must be recorded for fixing later

Log technical details at the time of the fault

Time, user, application, errors, etc

Identify seriousness of the fault

4. Performance Management and Accounting

Statistical information is gathered at various points in the system to provide raw

information for the activity

8/7/2019 AIT 600-test

10/24

Use data to predict future needs

Use for performance tuning

Generate billing information

Use for determining service-level requirements

Maintenance

Usually done at night when network and system traffic is lighter

Define night in a global system

Critical and routine updates/releases are done at defined intervals

Depends on how critical

Define critical

Systems Administration Group

Ensure configuration changes are made in an orderly fashion and time

Operations Group

Ensures the system is running

Monitors systems

Works with Systems Administration group to implement changes

Fault and Tracking Group

Investigates and Resolves errors with Operations groups

Performance Management Group

Provide short-term performance monitoring

Provide long-term capacity planning

Consider Automating Processes and Tasks

Large-scale systems need automation

Too many tasks for manual intervention

8/7/2019 AIT 600-test

11/24

Reserve complex decision making and review for humans

Silo vs. Distributed System

Which is simpler?

Which is easier to manage?

Which is easier to implement components?

Operational Systems Management

Monitor and Control

Interacts directly with the system and monitors what is going on

Process and Manage

Processing and recording information, and displaying information to

operators

Managed Object contains the Monitor and Control element in the form of an Agent

Anything needing management

Application, database, card in router

Manager contains the Process and Manage element

May also contain an Agent

Rules Engine

A filtering agent that only lets the necessary information flow through to the

database for processing

Saves processing, network, memory, etc.

Two groups of systems management products

Point Products perform a specific aspect of management

Suite Products provide a complete suite of services for systems management

Both can be integrated and automated

Autonomic Management

8/7/2019 AIT 600-test

12/24

Allow systems to be self-healing, detecting and correcting problems

Any problems with this?

Report errors for fixing later

Chapter 10 & 11

Chapter 10 - Security

Major Security Concerns

Authentication

Access Control

Protection

Security Management

Authentication

Identifying a user is who they say they are

How can we do this?

Access Control

AKAAuthorization

Giving an Authenticated user the authority to use a resource in a specified way

Any examples?

Protection

Stopping unauthorized access to resources

Can be divided among any number of categories to review for proper protection

See next slide

Protection Continued

Confidentiality only access to needed resources

8/7/2019 AIT 600-test

13/24

Integrity protection against tampering

Nonrepudiation retains originator integrity

Example: digital signature

Denial of Service protection against malicious service blockages

Physical Protection physically locking up the building/equipment

Security Management

How security will be administered

Who grants/denies access

Who decides who/what has access to what

How security breaches are handled

Automated reporting?

Manual reporting?

What Security is needed?

Define a list of security requirements BEFORE designing implementation

architecture

Look at the Data first!

Decide who needs to see what

Grant minimum level access

Decide who need to modify what

Deny all others

Define User Roles

Groups of Users will have the same needs to view/modify data

Easier to manage

Has potential for granting too much access

8/7/2019 AIT 600-test

14/24

Read-Only Users

Manager Roles

Running Reports

No data modification needed

Assigning Roles

During planning stage, state intended actions

During implementation the needs or access levels may change depending on

implementation strategy or changes made since initial plan

If Data is Duplicated

How is access controlled?

Access level strategies need to be consistent and synchd with anywhere

the data is being ported

You do not want to deny access on one system and open it up on another

How to prevent Internal Fraud

Multiple Level Authorizations

2 or more employees must give authorization for something to be

approved

Use fast detection systems to quickly identify suspicious activity

Build in recovery procedures for access violations

Auditing

Logging

Log suspicious activity

Log User Logins

Successful and Failed

Automatic notification to Admin of violations

8/7/2019 AIT 600-test

15/24

Access to Secure Information

Require Multiple-Authentication

2 or more users need to approve before access is granted

Can be physical, biometric, electronic

Can be isolated to specific terminals

Can also be Video surveillance to ensure user access is logged

Daily Reports of Access reviewed

Auditing User Activity

Who should be in charge of auditing?

What should they look for?

Who would they report it to?

What actions could be taken?

How could it be done?

Distributed System Security

The Onion Model

A Layered Approach

Things on the inside are protected

Authentication needs to be done at every layer

Outside layer is protection to inner layers

Resource and access point on every layer

Access Points authenticate access from each outside layer

To access inner core layers, authentication must occur from each outer

layer

Access Points

8/7/2019 AIT 600-test

16/24

Firewalls

Middleware

Server system software

Custom code

All of the above will attempt to keep out unauthorized access

Authenticating Server

Located on outer layer

Must be physically secure too

Controls all access to system

Must be strong authentication or an intrusion could assume the identity of any

user and access anything inside the inner layers

Must be kept current with patches/updates to combat the most current threats

Location Security

Messages of a certain kind are restricted from coming from only a particular

location

Restricts updates/access requests to come from only one server

Unauthorized server requests would be denied and logged

Location Security Continued

Firewalls can provide protection

Separate networks can provide location security

Branches of company on separate networks

Departments operating on separate networks

Boiling Lava Model

Multiple Security Management regimes being used to different parts of the system

Result of Silo systems being networked together

8/7/2019 AIT 600-test

17/24

Each silo having its own security

Departmental policy to have each department manage their own access

Boiling Lava Threats

Users need multiple logon ids

Writing down passwords and ids are a problem

Sharing user credentials to others since access is difficult

User access may not be rescinded when employee leaves organization

Single Sign-On

User logs on once and is granted access to everything using single sign-on

software

Good and Bad, Why?

Boiling Lava Model

Confidence in security?

Is it secure?

Is it consistent?

Is there a central authority?

Should it be implemented?

Web Services Security

Onion Model doesnt work on the Web

On the web, all services are peers and not layered

Example: A crate of apples

Little possibility of location security

Assumptions of authentication are not made

Secure Sockets Layer (SSL)

8/7/2019 AIT 600-test

18/24

https:// web address prefix

Opens a session using encryption keys that are sent with messages

Userid / password software can also be used with SSL to enhance security

SSL sets up secure session

Logon is performed

Security Tokens

Embedded user information in the message

Can contain userid, access level, time

Similar to your work id used for building access, but it is electronic

May contain a hash to verify tampering

A verifiable digit that can be decrypted

WS-Trust Standard

Requestor contacts Security Token Service to get a token

Requestor contacts web service and includes token

Web Service uses token received and contacts Security Token Service to validatethe token

Web Service grants access upon successful validation of token

5 Main Implementation Questions

1. Which applications belong in which security context?

2. Where is authorization going to take place?

3. Where is access control going to take place?

4. Where is security management going to take place?

5. What threats exist and what are the countermeasures?

Implementation Planning

8/7/2019 AIT 600-test

19/24

Use a network diagram and overlay security

Indicate where access control points will be located

Indicate where authentication will take place

Access Control

Where will this occur?

Can occur at the server

Can occur at a place prior to the application services

Integrating Existing Security

Access Control points connect old and new

Provide a consistent security policy

Bridge the old policies with the new over time

Chapter 11 - Application Design and IT Architecture

Design Up-Front or As-Needed?

I say Up-Front!

Modify as-needed later in a phased approach

Waterfall Development?

RAD?

Waterfall Development

Gather all of the requirements up front and develop

Easier to make changes to fix problems in the requirements gathering

stage then in the design or programming phase

Problems with Waterfall Development

End users and the business do not know the requirements, so how do they know it

is right?

8/7/2019 AIT 600-test

20/24

Difficult to express the design to programmer and sponsor in a clear manner

Division between requirements, design and implementation leads to over

engineering the project

Iterative Development

A series of waterfall developments overlapping one another

Rapid Application Development (RAD)

Combated waterfall approach in that it allowed for a prototype to be

created and tweaked to give customer what they want, and more quickly

Eliminated the rigorous requirements gathering

Business Rules

Information in databases are facts about the real world

Define the structure of these facts and how they are processed

Tony Morgans view of Rules

5 rule patterns

Tony Morgans 5 Rule Patterns

1.Constraints dependent on meeting a single criteria

2.List Constraints dependent on meeting a set of criteria

3.Classification if a certain criteria met, then something happens

4.Computation formula to compute

5.Enumeration some standard is met

Rules can be translated to Code

Using If / Then criteria

Is a contrast to some ways of thinking where Rules must always be true

What problems do you see with this?

Existing Systems

8/7/2019 AIT 600-test

21/24

2 Classes of Programmers

Lowly Maintenance Programmer

Superior New Application Development Programmer

What do you think?

Reuse of Components

1.Programmer who writes reusable components

2.Assembler who writes scripts to call the components

3.Administrator who writes the deployment descriptors and configures the

production system

Serendipitous Reuse

Components likely do not fit every need

Components may do more than you need

Wrong technology Java vs COM

Security interfaces dont work

Component assumptions dont fit

May work in small applications

Architectural Reuse

Define reuse opportunities while you are designing architecture

Reuse only occurs if you design it

Define the interfaces and look for components to implement the interfaces

Architectural Reuse

Components most likely to be reused:

Horizontal Components consistent use of error reporting, printing and

security components

Interface to Common Data customer and product data

8/7/2019 AIT 600-test

22/24

Interface to Common Routines calculations and data manipulation

Reuse is good for:

Screen layouts

Screen format parts

Design patterns

Documentation

Testing routines

Organizations are always looking for:

Faster Development

Cost Reduction

Better Security, Reliability and Performance

Enterprise Architecture will help

Enterprise Architecture Provides for:

Combining existing services in lieu of writing new ones

Cost reductions through less technologies to support

Better security, reliability, and performance through infrastructure support being

pushed out globally

Levels of Design

Outside of IT

Understand

Brainstorm

Clarify

Analysis

Repeat clarification and analysis

8/7/2019 AIT 600-test

23/24

Go down a level of detail and find or design the components

Levels of Design

IT

Gather Requirements

Design Solution

Implement Solution

Levels of Design

IT

Business Process Level Design

Is there already something available

Define Tasks

How does the user interact with the data

8/7/2019 AIT 600-test

24/24

Documents

AIT 600-test