New Technology Phase Change Memory

Introduction

My Dear friends this article discussed molecular memory, phase change memory, holographic memory, and magneto-resistive RAM. In this article I thought I’d revisit that article and expand a bit on the section discussing phase change memory. This will also give me a chance to introduce some advances in the technology recently announced by IBM.

Background

To understand the new advances made by IBM researchers you’ll need to know the basic science behind phase change memory and the challenges associated with it. Phase change memory is really very similar to the technology used in CD-R and DVD-R technologies.
In optical disc writing, a laser changes the opacity of small regions on the disc. The laser can make the small region more opaque or less opaque. It does this by changing the material from an amorphous state to a crystalline state or from a crystalline state to an amorphous state. When a disc reader then reads the reflection from the disc the reader will be able to determine if the region is in an amorphous or a crystalline state thus reading either a logical ‘1’ or a logical ‘0’.
Likewise, phase change memory also changes a small region from an amorphous state to a crystalline state and back again. In phase change memory implementations though, this change is done via an electrical current instead of a laser. More precisely, it is the heat that can change the state the optical disc and phase change memory implementations merely change how that heat is created/distributed. In my previous article Memory Storage, I highlighted the scientific similarities of resistivity to opacity, which even includes reflection!
Phase change memory systems can determine whether a region, often called a cell, is in an amorphous or crystalline state by measuring its electrical resistivity. This leads to one of the major advantages of a phase change memory system; the resistivity levels of amorphous and crystalline states are drastically different. This allows us to implement different levels of crystallization so that each region can have not just two states but potentially several states. This type of storage where one region can have multiple states is referred to as MultiLevel Cell (MLC) storage.

Advantages

Since phase change memory implementations are quite expensive to produce it is believed that a significant implementation of MLC storage will allow for very large amounts of storage and justify the high price of the technology in a competitive market. Of course, MLC storage isn’t unique to phase change memory implementations; it’s also seen in flash based memory. In flash based memory storage solutions it’s common to see four states supported per cell. This provides two bits of storage for each cell - as opposed to one bit per sell for Single Level Cell (SLC) storage.

Figure 1: attributes of phase change memory (PCM) compared to other types (Courtesty of hothardware.com)

Other than MLC, what are some other advantages of phase change memory solutions? Well, like flash, there are no moving parts which increase longevity and usability. Also, since the cell states are changed with heat via an electric pulse, there is no danger in having small magnets in close proximity to the memory. Also, these electrical pulses can change the states very quickly which can result in significantly faster write times when compared with flash.

Challenges

There are some drawbacks to MLC storage. Since there are more states stored in a single cell there is less of a difference between these states which can result in a higher bit error rate (BER). In flash based memory storage solutions this can be adequately handled via an increased role for error correction modules. The increased error correcting could potentially slow down an application, but this is the trade off for getting basically double the storage in the physical area.
In phase change memory the effect of having four states per cell is even more dramatic than in the flash based implementations. This is due to the cells having what’s known as a resistance drift. A resistance drift describe the effect of the resistance level of the different states chaning - or drifting - over time.
So you may be asking - what’s the big deal about this resistance drift? Can’t we just store a known value in some cells and measure the drift over time, then compensate for the drift when reading from the other cells? Yes, we could, if the drift was uniform across the cells. It’s not. The resistance drift is somewhat erratic and cannot be compensated for in this manner.

Group Policy Design principle

Active Directory Group Policy Design Principles

Finally we go to Group Policies. Personally, I find this feature one of the more compelling reasons to make the move to Active Directory. Properly designing and implementing it.
Group Policy processing rules of thumb
These are my 5 rules of thumb I tried to remember when I was taking up the Active Directory Implementation and Active Directory Design exams, and in my subsequent Group Policy design exercises.
Rule 1 – Execution Order: L > S > D > OU. Local policies are procesed first. Then follows the Site GPO’s, then Domain GPO’s, then OU GPO’s from top level OU until the direct container of the user or computer object. Any conflicting settings and the last processed GPO will prevail.
Rule 2 – Inheritance. GPO setings are inherited from the top level containers containers to the direct container of the user or computer object. If we need to remove the Run Menu from all users in our domain, we simply need to create the GPO for this and link it to our domain, instead of linking it on all OU’s where there are user accounts. There are of course, exceptions to the rule.
Rule 3 – Block Inheritance. Block Inheritance is applied to the container and ensures that any policy in the upper level containers are not applied to the container that it is applied to and the downstream containers. This is intended as an exception to Rule # 2 on Inheritance. The proper application to this is a downstream container.

Rule 4 – Link Enforced. Enforcing the link ensures that the GPO will be executed no matter what downstream GPO’s are applied to downstream containers. This provides an exception to Rule # 1 on Execution Order. The proper application to this is an upstream link. Note that Enforced is applied to the link, meaning the should GPO may be linked to more than one container, only those that we applied Enforced are those that will be enforced. Enforcing the link is a powerful exception that overrides the Block Inheritance exception

Rule 5 – GPO Access Control. If, for example, one would intend to enforce a specific GPO only to a subset of user accounts in an OU, we only need to change the default Access Control List of the GPO to allow both Read and Apply Group Policy to those user accounts that need to be enforced with the policy (we need to remove Authenticated Users from this ACL in the process). On the other hand, if we wish that a specific subset of users, say for example, Administrators SHOULD NOT be enforced with, say for example, a restrictive GPO, then we can just grant them Deny permissions on Apply Group Policy. Note that the Enterprise Admins, Domain Admins and Administrators groups are not subject to Group Policies because these group accounts are not given the Allow permission in Apply Group Policy permission by default, but they are also not explicitly given a Deny permission. This means that, making a user account a member of these groups does not necessarily liberate that user account from restrictive Group Policies. For really restrictive policies that endanger an administrative account being locked out, it is best to explicitly give the said group accounts the Deny permission on the Apply Group Policy access control entry.


Key pointers in designing and implementing Group Policies

1. Although one can link a GPO to the Site container, it is not adviseable, given the fact that a site can contain multiple Domain Controllers from different domains.
2. As mentioned in the OU Design document, implementing a wide but shallow OU structure is better than a narrow but deep structure for performance purposes. The deeper the OU, the more Group Policies that need to be processed and the longer it takes to start up the machine and/or log on the user. Although a wide but deep structure would eventually mean more GPO’s and more links, less GPO’s need to be enforced during the startup or logon process.
3. Ensure that the Distributed File System (DFS) is working properly between domain controllers in the same domain. DFS is the means for the Group Policy files to be transferred between domain controllers. If DFS is malfunctioning, it is possible that multiple, copies of the same GPO get propagated and enforced on the client machines. Depending on the nature of the GPO, this can pose a serious security threat to the network.
4. Download and install the Group Policy Management Console (GPMC)
5. Learn the proper usage of Block Policy Inheritance and Link Enforced. Refrain from using these exceptions if you can get away with it. Remember: Block Policy Inheritance is applied to a downstream container, while Link Enforced is applied to an upstream Link.

Auditing a DNS Zone

1. Introduction

One of the main aspects of security is the maintenance and to do that correctly the administrator needs to be able to track changes that are done in the environment. There are a lot of challenges on this area and one of the biggest challenge is to log what needs to be logged without overwhelm the server.

When I was working in the platforms team I remember that I received a call from a customer saying that he wants to know who deleted a record on his DNS Zone. First question was:  do you have an audit policy for DNS enable?  He was like: what is that?  After review his environment I saw that the auditing was enabled, but not for the Active Directory Objects (his DNS Zone was integrated to AD).

This post will walk through the Auditing configuration of a DNS Zone (AD Integrated) on Windows Server 2003.

2. Preparing the Environment

There are three steps to prepare the environment:

·         Verify if the Audit Policy called Audit Directory Service Access is enabled and what is the setting.

·         Enabled the Auditing on the DNZ Zone that you want to audit.

·         Use the Event Viewer to find out which object of modified (in this case the example will be an object deletion).

3. Configuring the Audit Policy

Open the Default Domain Controllers Policy, and check if the policy highlighted below is selected just like that:

Figure 1 – Configuring Upload and Download Policy.

In my case I changed to audit Success and Failure, but the final configuration will be according to your needs.

4. Configuring the DNS Zone

Now that we have enabled the Audit Policy to all Domain Controller in the domain, we need to change the DNS Zone. To do that follow the steps below:

1) Open ADSIEdit (Start / Run / ADSIEDIT.msc)

2) Right click in the ADSI Edit and click in Connect To…

3) In the Connection Settings window, configure just like show below:

 

Figure 2 – Connection Setting.

Note: Change the dc= to reflect your domain name.

4) After that click OK.

5) Now expand the container until you get to the same node as show below:

 

Figure 3 – Configuring the Zone.

5) Right click in the name of the zone located under CN=MicrosoftDNS and click in Properties.

6) Click in Security and then Advanced.

7) Click in Auditing and click in Add.

8) Type Everyone and click OK. Add the following type of access:

·         Write All Properties

·         Delete

·         Delete Subtree

9) Click OK on all three windows.

Now we are ready to log !!

5. Testing

For testing purpose I delete the record called work01 and here what you should see on the security event log:

Event Type:    Success Audit

Event Source:  Security

Event Category:         Directory Service Access

Event ID:          566

Date:               3/5/2008

Time:               7:33:51 PM

User:                CONTOSO\Administrator

Computer:       DCCONT

Description:

Object Operation:

            Object Server: DS

            Operation Type:          Object Access

            Object Type:    dnsNode

            Object Name:            DC=work01,DC=contoso.msft,CN=MicrosoftDNS,DC=DomainDnsZones,DC=contoso,DC=msft

            Handle ID:       -

            Primary User Name:   DCCONT$

            Primary Domain:        CONTOSO

            Primary Logon ID:       (0x0,0x3E7)

            Client User Name:      Administrator

            Client Domain:            CONTOSO

            Client Logon ID:          (0x0,0x19062D)

            Accesses:         Write Property

                                   

            Properties:

            Write Property

                        Default property set

                                    dnsRecord

                                    dNSTombstoned

            dnsNode

            Additional Info:          

            Additional Info2:        

            Access Mask:   0x20

Note the following points in red (from top to down):

·         The event type: the user was able to successfully perform this operation.

·         Category: the object was categorized as a DS Object.

·         User: the name of the user that performed this operation.

·         Object Name: the complete path from where the object was located.

·         dNSTombstoned: this is probably the only one that is not friendly. This attribute is logged whenever an object is deleted. For more information review the DNS-Tombstoned Attribute at MSDN.

Great Information On Microsoft Active Directory

http://jpaloma.wordpress.com/

Exchangepedia: How to create a Recipient Policy based on Company names?

Exchangepedia: How to create a Recipient Policy based on Company names?

Configuring Network Prioritization on a Failover Cluster

This blog will describe the Network Prioritization feature and how to configure it.  Network Prioritization is used to designate which type of traffic should be directed through which network in a Failover Cluster running Windows Server 2008 R2.  When designing a highly-available infrastructure, it is important to avoid any single points of failure, so there should be redundancy in all the hardware components, including the servers, storage and the networking.  For this reason we recommend and assume that there are multiple networks in your cluster.  If a network is unavailable Windows Server Failover Clustering will automatically direct traffic through another network to maintain service availability for applications or VMs.  However some networks may be preferred for certain types of traffic based on the network’s speed, security or function, so it can be important to designate which network is used for which purpose.

Types of Cluster Network Traffic

Understanding the different categories of networking traffic can help you plan the best use for your networks. 

Cluster & CSV Traffic

We define cluster traffic as the information needed for the nodes to communicate with each other to ensure that it functions correctly.  This can include communication such as heartbeats for health-checking, updates to the cluster database, join requests from partitioned nodes, and much more.  Additionally Cluster Shared Volumes (CSV) traffic will use this network for metadata updates, or when it is in redirected mode, meaning that a node hosting a VM cannot directly assess its disk, so it redirects the traffic via another node to that disk.  This can be configured by right-clicking on the network in Failover Cluster Manager, selecting Properties, and selecting the radio button for “Allow cluster network communication on this network”.

Live Migration Traffic

If a cluster is taking advantage of the live migration feature to move running Virtual Machines (VMs) between cluster nodes, then live migration traffic is an important consideration.  During a live migration, large chunks of memory are copied from one server to another as quickly as possible.  This burts the network with heavy traffic, and can block other types of network communication from getting through.  For this reason it is recommended to have a dedicated network for live migration traffic so that it does not interfere with other important network traffic.  Live migration is commonly used when a physical host needs planned maintenance (such as patching and a reboot), so running VMs are live migrated from that host to avoid any downtime for the VM guests.  The faster that this network is, the more traffic can pass through it, thus the host can be evacuated quicker, so it is very common to see the fastest network being dedicated towards live migration.  This can be configured by right-clicking on the network in Failover Cluster Manager, selecting Properties, selecting the radio button for “Allow cluster network communication on this network”.

Public Traffic

Whether the cluster is providing high-availability for VMs, SQL databases, File Servers or anything else, a “client” needs to access that application, service or VM.  A “client” is defined loosely as a user or application which needs to communicate with that workload running on the cluster.  For the client to access that data, they need to make requests and have data sent back to them through those networks.  These networks are generally less secure as they are more exposed and accessible, and they could be subject to network flooding, which could impact performance or throughput of traffic.  For this reason it is recommended that you do not use this network for cluster traffic, live migration or any other use and to explicitly open it up to clients.  This can be configured by right-clicking on the network in Failover Cluster Manager, selecting Properties, selecting the radio button for “Allow cluster network communication on this network” and selecting the checkbox “Allow clients to connect through this network”.

Storage Traffic

If your cluster uses iSCSI or Fibre Channel over Ethernet (FCoE) for the cluster’s shared storage, this traffic goes through an Ethernet network which the cluster will identify as a cluster network.  To avoid storage I/O performance being affected with iSCSI or FCoE, it is recommended that you provide a dedicated network for storage traffic so that other network traffic does not interfere with this data.  For this reason it is recommended that you do not use this network for cluster traffic, live migration or any other use.  This can be configured by right-clicking on the network in Failover Cluster Manager, selecting Properties, and selecting the radio button for “Do not allow cluster network communication on this network”. 

Network Prioritization

Since it is a best practice to use multiple networks in your cluster, there is likely the need to specify the function for the various cluster networks.  This can be done on Windows Server 2008 R2 through the Network Prioritization (NP) feature.  NP will list the order of cluster networks and give the ability for the networks to be “ranked”, where different ranks indicate different network roles.  To rank a network, it is given a unique integer from 1 to 268,000,000+, which is called a “metric”.   

To view the networks, their metric values, and if they were automatically or manually configured, run the clustering PowerShell cmdlet:
PS > Get-ClusterNetwork | ft Name, Metric, AutoMetric

 By default, all internal cluster network will have a metric value starting at 1000 and incrementing by 100.  The first internal network which the cluster sees when it first comes online has a metric of 1000, the second has a metric of 1100, etc.  We assume that a network is ‘internal’ if it does not have access to a default gateway.  The initial list of internal networks is determined by the order which the network adapters were seen by the cluster when it was created.

By default all external cluster network will have a metric value starting at 10000 and incrementing by 100.  The first external network which the cluster sees when it first comes online has a metric of 10000, the seconds has a metric of 10100, etc.  We assume that a network is ‘external’ if it has access to a default gateway.  The initial list of external networks is determined by the order which the network adapters were seen by the cluster when it was created.

The cluster will then use the order of the metrics as the order of networks.  The lowest network will be used for “Cluster & CSV Traffic”.  The second lowest network will be used for “Live Migration Traffic”.  Additional networks with a metric below 10000 will be used as backup networks if the “Cluster & CSV Traffic” or “Live Migration Traffic” networks fail.  The lowest network with a value of at least 10000 will be used for “Public Traffic”, and any additional networks with a metric above 10000 will be used as backup networks for “Public Traffic”.  Give the highest possible values to any networks which you do not want any cluster or public traffic to go through, such as for “Storage Traffic”, so that they are never used, or only used when no other networks at all are available, depending on your settings.

So let’s say you get the following output from running
PS > Get-ClusterNetwork | ft Name, Metric, AutoMetric

     Name                       Metric     AutoMetric
     ----                       ------     ----------
     Cluster Network 1          1000       True
     Cluster Network 2          1100       True
     Cluster Network 3          1200       True
     Cluster Network 4          10000      True
     Cluster Network 5          10100      True

In this scenario, these networks would carry the following types of traffic:

·    Cluster Network 1 (1000) – Cluster & CSV Traffic

·    Cluster Network 2 (1100) – Live Migration Traffic

·    Cluster Network 3 (1200) – Backup network for Cluster & CSV Traffic and Live Migration Traffic

·    Cluster Network 4 (10000) – Public Traffic

·    Cluster Network 5 (10100) – Backup network for Public Traffic

Configuring Network Prioritization

It is possible to customize NP if the cluster does not automatically assign networks to use the traffic pattern that you want, which will change the ranked order, and hence the function.  For example, you may want Cluster Network 3 to be used for “Live Migration Traffic” as it is the fastest, so you would change its Metric to a value between 1000 and 1100, such as 1050, so that it is ranked second on the list.  Once Cluster Network 3 has the second-lowest metric it will be used for Live Migration Traffic.

To change the value of a network metric, run:
PS > $n = Get-ClusterNetwork “Cluster Network 3”
PS > $n.Metric = 1050

This will change the metric of Cluster Network 3 to 1050. 

Now you get the following output from running
PS > Get-ClusterNetwork | ft Name, Metric, AutoMetric

     Name                       Metric     AutoMetric
     ----                       ------     ----------
     Cluster Network 1          1000       True
     Cluster Network 3          1050       False
     Cluster Network 2          1100       True
     Cluster Network 4          10000      True
     Cluster Network 5          10100      True

You may have noticed that is a property associated with each network called AutoMetric.  This indicates whether the Metric was set using the default values (True) or if it had been later adjusted by an admin (False).  This gives insight into whether NP has been configured on the cluster.  Using this flag, it is actually possible to change the value of a network back to its original and automatically assigned value, by running the cmdlet:
PS > $n = Get-ClusterNetwork “Cluster Network 3”
PS > $n.AutoMetric = $true 

Overriding Network Prioritization Behavior

There are two ways to override the default behavior of NP.  The first is by changing the network’s properties by right-clicking on the network in Failover Cluster Manager, selecting Properties, and changing the radio buttons or checkboxes.  For example, if you select “Do not allow cluster network communication on this network”, then it will not be possible to send any “Cluster & CSV Traffic” or “Live Migration Traffic” through this network, even if the network has the lowest metric values.  The cluster will honor this override and find the network with the next lowest value to send this type of traffic.

The second override is exclusively for “Live Migration Traffic”.  The networks for live migration can be configured more granularly by right-clicking on any Virtual Machine resource, selecting Properties and clicking the Network for live migration tab.  Here you have the ability to specify which networks can and cannot be used for “Live Migration Traffic” and in which order they should be used.  Even though it appears that this setting may be unique to that specific VM, it is actually a global setting for live migration.  This means that it will override the “Live Migration Traffic” network configured through NP and all VMs will perform a live migration through the network(s) specified here.  If this setting is change multiple locations, the last change will be honored.

  

With this information we hope you are better able to understand how to deploy, configure and use your cluster networks to get the optimal performance and function from each