The rows in a clustered index are physically stored on the disc in the same order as the index. As a result, only one clustered index is possible.
There is a second list with references to the physical rows in a non clustered index. You can have a lot of non-clustered indices, but each one increases the amount of time it takes to create new entries.
If you wish to get all of the columns, it's usually faster to read from a clustered index. It is not necessary to go to the index first and then to the table.
When you create a clustered index, you're directing the database to store values that are physically close to one another on the disc. This has the advantage of allowing for a quick search and retrieval of data that fall inside a certain range of clustered index values.
For example, let us take two tables: Customer and Order:
Customer
----------
ID
Name
Address
Order
----------
ID
CustomerID
Price
Create a clustered index on the "CustomerID" column of the Order table if you want to easily obtain all orders for a certain customer. This method, entries with the same CustomerID are physically stored near one other on storage (clustered), making retrieval faster.
P.S. Because the index on CustomerID is obviously not unique, you'll need to either add a second column to "uniquify" the index or let the database handle it for you, but that's an other issue.
Concerning the use of multiple indices, because this dictates how the data is physically structured, each table can only have one clustered index. Imagine a large room with several tables if you want an analogy.
